diff options
Diffstat (limited to 'results/classifier/zero-shot/108/none')
399 files changed, 41747 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/none/1013691 b/results/classifier/zero-shot/108/none/1013691 new file mode 100644 index 000000000..d7599868b --- /dev/null +++ b/results/classifier/zero-shot/108/none/1013691 @@ -0,0 +1,40 @@ +graphic: 0.587 +device: 0.549 +semantic: 0.443 +other: 0.382 +performance: 0.315 +network: 0.266 +PID: 0.249 +socket: 0.248 +boot: 0.232 +permissions: 0.213 +vnc: 0.205 +debug: 0.189 +files: 0.104 +KVM: 0.056 + +ppc64 + virtio-scsi: only first scsi disk shows up in the guest + +When adding two virtio-scsi targets to a single guest, only the first +disk is seen inside the guest. For some unknown reason the guest +doesn't enumerate the second disk. + +For full qemu-system-ppc64 command line and 'dmesg' output, see: + +http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02430.html + +I have also tried this with Linus's git tree (3.5.0-rc2+ at time of writing), +same thing. + +In both cases I'm using qemu from git. + +Can you test whether the spapr-vscsi controller works instead? + +Yes, that works fine, both disks seen by the guest. + +Only just saw this bug, I assume the problem still exist ? I have somebody look at it next week + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU and guest kernel? Or could we close this ticket nowadays? + +Closed it, very old bug and we successfully test many disks with ppc64/le nowadays. + diff --git a/results/classifier/zero-shot/108/none/1015 b/results/classifier/zero-shot/108/none/1015 new file mode 100644 index 000000000..18acbb0bf --- /dev/null +++ b/results/classifier/zero-shot/108/none/1015 @@ -0,0 +1,16 @@ +other: 0.405 +semantic: 0.392 +graphic: 0.380 +performance: 0.361 +device: 0.121 +permissions: 0.116 +network: 0.105 +PID: 0.066 +debug: 0.052 +boot: 0.052 +vnc: 0.035 +KVM: 0.027 +socket: 0.027 +files: 0.017 + +qemu-7.0 there is no device "hostdev0" defined diff --git a/results/classifier/zero-shot/108/none/1037 b/results/classifier/zero-shot/108/none/1037 new file mode 100644 index 000000000..36bc98b98 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1037 @@ -0,0 +1,16 @@ +device: 0.426 +permissions: 0.412 +performance: 0.295 +semantic: 0.215 +graphic: 0.183 +network: 0.113 +vnc: 0.050 +PID: 0.031 +other: 0.029 +socket: 0.029 +debug: 0.025 +files: 0.021 +boot: 0.016 +KVM: 0.013 + +Let's encrypt certificate for *.qemu.org has expired diff --git a/results/classifier/zero-shot/108/none/1042654 b/results/classifier/zero-shot/108/none/1042654 new file mode 100644 index 000000000..13f89b73d --- /dev/null +++ b/results/classifier/zero-shot/108/none/1042654 @@ -0,0 +1,105 @@ +semantic: 0.587 +debug: 0.563 +device: 0.551 +other: 0.543 +network: 0.541 +PID: 0.512 +permissions: 0.496 +socket: 0.442 +vnc: 0.404 +files: 0.400 +performance: 0.387 +graphic: 0.379 +boot: 0.314 +KVM: 0.310 + +Floppy disks and network not working on NT 3.1 on Qemu 1.2 rc1 + +When I try to put Floppy IMG/IMA/VFD images on NT 3.1 when it is running on Qemu 1.2 rc, they are not recognized and the network is not working even though I set it correctly (especially the AMD PCnet adapter) +Here's some screenshot of the floppy error: +http://i49.tinypic.com/j77wcw.png + +On Tue, Aug 28, 2012 at 10:29 AM, TC1988 <email address hidden> wrote: +> Public bug reported: +> +> When I try to put Floppy IMG/IMA/VFD images on NT 3.1 when it is running on Qemu 1.2 rc, they are not recognized and the network is not working even though I set it correctly (especially the AMD PCnet adapter) +> Here's some screenshot of the floppy error: +> http://i49.tinypic.com/j77wcw.png + +Thanks for testing qemu 1.2-rc! + +Can you confirm that both floppy and AMD PCnet worked in QEMU 1.1? + +If so, could you please try running git-bisect(1) to identify which +commit introduced the breakage? + +$ git clone git://git.qemu.org/qemu.git +$ cd qemu +$ git bisect start v1.2-rc1 v1.1.0 + +For more info on git-bisect(1): +http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search +http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html + +Stefan + + +they worked in Qemu 1.1 and also in the previous versions and, by the way, I can't compile, I used a third party Win32 build of Qemu 1.2 rc1. :( + +On Wed, Aug 29, 2012 at 1:53 PM, TC1988 <email address hidden> wrote: +> they worked in Qemu 1.1 and also in the previous versions and, by the +> way, I can't compile, I used a third party Win32 build of Qemu 1.2 rc1. +> :( + +Have you tried any other guest operating systems? If there is a more +readily available guest OS that shows the same bug it would allow +others to reproduce and debug this. + +Stefan + +> https://bugs.launchpad.net/bugs/1042654 +> +> Title: +> Floppy disks and network not working on NT 3.1 on Qemu 1.2 rc1 +> +> Status in QEMU: +> New +> +> Bug description: +> When I try to put Floppy IMG/IMA/VFD images on NT 3.1 when it is running on Qemu 1.2 rc, they are not recognized and the network is not working even though I set it correctly (especially the AMD PCnet adapter) +> Here's some screenshot of the floppy error: +> http://i49.tinypic.com/j77wcw.png + + +it does not happen on NT 3.5, 3.51 or 4.0, only on 3.1. + +Found someone who had a copy of NT 3.1 handy and he bisected it to: + +commit 2fee00885a9ea4db69bbfc1ba8ccf95f2ae9aec6 +Author: Pavel Hrdina <email address hidden> +Date: Fri Jun 22 12:33:55 2012 +0200 + + fdc: fix interrupt handling + + If you call the SENSE INTERRUPT STATUS command while there is no interrupt + waiting you get as result unknown command. + + Fixed status0 register handling for read/write/format commands. + + Signed-off-by: Pavel Hrdina <email address hidden> + Signed-off-by: Kevin Wolf <email address hidden> + +nice :) but what about the network? + +It appears that the fdc issue were addressed in this patch series: + + http://thread.gmane.org/gmane.comp.emulators.qemu/168836 + +Unfortunately the URL from comment #7 is dead nowadays ... has this fix been committed to the QEMU repository? + +The floppy fix appears to be commit 34abf9a7 (contained in qemu 1.3). + +I don't think anyone ever looked into the networking problem. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1054 b/results/classifier/zero-shot/108/none/1054 new file mode 100644 index 000000000..c9d5243e8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1054 @@ -0,0 +1,45 @@ +graphic: 0.450 +device: 0.368 +debug: 0.305 +performance: 0.281 +semantic: 0.253 +permissions: 0.253 +boot: 0.240 +vnc: 0.212 +PID: 0.197 +socket: 0.171 +other: 0.142 +network: 0.120 +files: 0.092 +KVM: 0.040 + +Unable to start CirrOS 0.5.1 on QEMU 7.0 with -M virt and -cpu max +Description of problem: + +Steps to reproduce: +1. Fetch CirrOS image: ```wget https://github.com/cirros-dev/cirros/releases/download/0.5.1/cirros-0.5.1-aarch64-disk.img``` +2. Run QEMU: + ``` + qemu-system-aarch64 -drive file=cirros-0.5.1-aarch64-disk.img -M virt -m 2048 \ + -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -cpu max -nographic + ``` +Additional information: +When image boots, GRUB window appears for a second and then kernel/initramfs are loaded and booted: +``` +EFI stub: Booting Linux Kernel... +EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied +EFI stub: Using DTB from configuration table +EFI stub: Exiting boot services and installing virtual address map... +``` + +When everything is fine we can see kernel output: +``` +[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070] +[ 0.000000] Linux version 5.3.0-26-generic (buildd@bos02-arm64-028) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #28~18.04.1-Ubuntu SMP Wed Dec 18 16:41:01 UTC 2019 (Ubuntu 5.3.0-26.28~18.04.1-generic 5.3.13) +[ 0.000000] efi: Getting EFI parameters from FDT: +[ 0.000000] efi: EFI v2.70 by EDK II +``` + +But on QEMU 7.0 with ```-M virt -cpu max``` we never get kernel output. + +# diff --git a/results/classifier/zero-shot/108/none/1054812 b/results/classifier/zero-shot/108/none/1054812 new file mode 100644 index 000000000..95467bfe4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1054812 @@ -0,0 +1,26 @@ +device: 0.530 +other: 0.324 +semantic: 0.220 +graphic: 0.174 +vnc: 0.104 +socket: 0.100 +boot: 0.091 +PID: 0.076 +network: 0.075 +debug: 0.072 +files: 0.061 +performance: 0.047 +permissions: 0.042 +KVM: 0.012 + +Configure uses wrong libtool on Darwin + +On Darwin/OS X, there are two versions of libtool: the GNU libtool, and Apple's libtool. Both are installed, but Apple's libtool (libtool) won't build libcacard that Qemu uses, but Gnu's libtool (glibtool) does. I get around using Apple's libtool by passing LIBTOOL=glibtool when configuring; unfortunately this variable isn't preserved so when Qemu's configure changes it's not passed. A simple switch in the configure script could check for Darwin, then if present, use glibtool. Or configure could check the features of libtool, see if they can build libcacard, then look for alternatives like glibtool. + +This bug was probably introduced when libcacard was added to Qemu, and is present in commit 93b6599734f81328ee3d608f57667742cafeea72. + +Since libcacard is not longer part of QEMU, I assume this is not an issue anymore today. So can we close this bug nowadays? + +Yes, libtool handling was removed entirely in commit e999ee443496b, so this bug is no longer present. + + diff --git a/results/classifier/zero-shot/108/none/1054831 b/results/classifier/zero-shot/108/none/1054831 new file mode 100644 index 000000000..33ee9e4d7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1054831 @@ -0,0 +1,69 @@ +PID: 0.179 +network: 0.173 +device: 0.169 +other: 0.150 +permissions: 0.129 +semantic: 0.116 +vnc: 0.106 +performance: 0.104 +socket: 0.104 +debug: 0.093 +files: 0.074 +graphic: 0.058 +KVM: 0.054 +boot: 0.046 + +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/zero-shot/108/none/1057 b/results/classifier/zero-shot/108/none/1057 new file mode 100644 index 000000000..78ebce525 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1057 @@ -0,0 +1,38 @@ +semantic: 0.521 +device: 0.491 +other: 0.379 +performance: 0.369 +debug: 0.344 +graphic: 0.233 +network: 0.207 +socket: 0.065 +KVM: 0.060 +vnc: 0.056 +permissions: 0.052 +boot: 0.050 +PID: 0.042 +files: 0.014 + +AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions +Description of problem: +I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction: +`0x0000000000000000: C3 44 00 B8 str w3, [x6], #4` + +notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting. + +Here is the relevant part of the manual: + +``` +For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts: +• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback). +``` + +However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions. + +Another example of instruction: `0x00000000000002f8: 01 1C 40 38 ldrb w1, [x0, #1]!` +Steps to reproduce: +1. Run some hypervisor in EL2 +2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP) +3. Observe the value of ESR_EL2 on data abort + +Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch. diff --git a/results/classifier/zero-shot/108/none/1100 b/results/classifier/zero-shot/108/none/1100 new file mode 100644 index 000000000..0fbef6c81 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1100 @@ -0,0 +1,16 @@ +device: 0.389 +graphic: 0.381 +other: 0.321 +permissions: 0.314 +semantic: 0.307 +performance: 0.194 +boot: 0.192 +PID: 0.158 +KVM: 0.150 +debug: 0.126 +network: 0.119 +socket: 0.097 +vnc: 0.061 +files: 0.059 + +It riscv64 platform support user model?? diff --git a/results/classifier/zero-shot/108/none/1120383 b/results/classifier/zero-shot/108/none/1120383 new file mode 100644 index 000000000..3ae796ba3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1120383 @@ -0,0 +1,162 @@ +permissions: 0.600 +graphic: 0.444 +PID: 0.425 +KVM: 0.424 +semantic: 0.404 +other: 0.393 +debug: 0.390 +vnc: 0.368 +performance: 0.356 +files: 0.302 +device: 0.301 +network: 0.289 +socket: 0.287 +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/zero-shot/108/none/1122 b/results/classifier/zero-shot/108/none/1122 new file mode 100644 index 000000000..591816d95 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1122 @@ -0,0 +1,143 @@ +other: 0.266 +semantic: 0.259 +debug: 0.248 +graphic: 0.244 +vnc: 0.243 +permissions: 0.241 +PID: 0.230 +device: 0.220 +KVM: 0.218 +performance: 0.177 +files: 0.166 +network: 0.164 +boot: 0.156 +socket: 0.120 + +ARMv7M (Cortex M) NVIC does not make number of priority bits a board/SoC-configurable parameter +Description of problem: +In FreeRTOS code for function of `xPortStartScheduler()` in [`main/portable/GCC/ARM_CM4F/port.c`](https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/ARM_CM4F/port.c#L293) file code sets the value of 0x400 register of NVIC to the maximum bits and expect to read back only maximum priority bits that are supported by the platform. The QEMU code doesn't unset these bits (same 0xff value written is read back): +``` +NVIC: priority [0x400] = 0x00 +NVIC[NS]: [0x400] -> 0x00000000 +NVIC: priority [0x400] = 0xff +NVIC[NS]: [0x400] <- 0x000000ff +nvic_recompute_state NVIC state recomputed: vectpending 0 vectpending_prio 256 exception_prio 256 +NVIC: priority [0x400] = 0x00 +NVIC[NS]: [0x400] -> 0x000000ff +``` +Logging function for reading and writing added in `hw/intc/armv7_nvic.c` like these: +writing: +```c + case 0x400 ... 0x5ef: /* NVIC Priority */ + startvec = (offset - 0x400) + NVIC_FIRST_IRQ; /* vector # */ + + for (i = 0; i < size && startvec + i < s->num_irq; i++) { + if (attrs.secure || s->itns[startvec + i]) { + qemu_log("NVIC: priority [0x%03x] = 0x%02llx\n", offset, (value >> (i * 8)) & 0xff); + set_prio(s, startvec + i, false, (value >> (i * 8)) & 0xff); + } + } + qemu_log("NVIC[%s]: [0x%03x] <- 0x%08llx\n", attrs.secure ? "S" : "NS", offset, value); + + nvic_irq_update(s); + goto exit_ok; +``` +reading: +```c + case 0x400 ... 0x5ef: /* NVIC Priority */ + val = 0; + startvec = offset - 0x400 + NVIC_FIRST_IRQ; /* vector # */ + + // TODO: should return either 0x70 or 0x78 + for (i = 0; i < size && startvec + i < s->num_irq; i++) { + qemu_log("NVIC: priority [0x%03x] = 0x%02x\n", offset, 8 * i); + if (attrs.secure || s->itns[startvec + i]) { + val |= s->vectors[startvec + i].prio << (8 * i); + } + } + qemu_log("NVIC[%s]: [0x%03x] -> 0x%08x\n", attrs.secure ? "S" : "NS", offset, val); + break; +``` +Steps to reproduce: +1. Run FreeRTOS for any ARMv7 Cortex-M platform with NVIC +2. Observe failure to proceed to `prvPortStartFirstTask();` function. +Additional information: +Here is the piece of standard FreeRTOS code that runs that check: +```c + /* configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to 0. + * See https://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html */ + configASSERT( configMAX_SYSCALL_INTERRUPT_PRIORITY ); + + /* This port can be used on all revisions of the Cortex-M7 core other than + * the r0p1 parts. r0p1 parts should use the port from the + * /source/portable/GCC/ARM_CM7/r0p1 directory. */ + configASSERT( portCPUID != portCORTEX_M7_r0p1_ID ); + configASSERT( portCPUID != portCORTEX_M7_r0p0_ID ); + + #if ( configASSERT_DEFINED == 1 ) + { + volatile uint32_t ulOriginalPriority; + volatile uint8_t * const pucFirstUserPriorityRegister = ( volatile uint8_t * const ) ( portNVIC_IP_REGISTERS_OFFSET_16 + portFIRST_USER_INTERRUPT_NUMBER ); + volatile uint8_t ucMaxPriorityValue; + + /* Determine the maximum priority from which ISR safe FreeRTOS API + * functions can be called. ISR safe functions are those that end in + * "FromISR". FreeRTOS maintains separate thread and ISR API functions to + * ensure interrupt entry is as fast and simple as possible. + * + * Save the interrupt priority value that is about to be clobbered. */ + ulOriginalPriority = *pucFirstUserPriorityRegister; + + /* Determine the number of priority bits available. First write to all + * possible bits. */ + *pucFirstUserPriorityRegister = portMAX_8_BIT_VALUE; + + /* Read the value back to see how many bits stuck. */ + ucMaxPriorityValue = *pucFirstUserPriorityRegister; + + /* Use the same mask on the maximum system call priority. */ + ucMaxSysCallPriority = configMAX_SYSCALL_INTERRUPT_PRIORITY & ucMaxPriorityValue; + + /* Calculate the maximum acceptable priority group value for the number + * of bits read back. */ + ulMaxPRIGROUPValue = portMAX_PRIGROUP_BITS; + + while( ( ucMaxPriorityValue & portTOP_BIT_OF_BYTE ) == portTOP_BIT_OF_BYTE ) + { + ulMaxPRIGROUPValue--; + ucMaxPriorityValue <<= ( uint8_t ) 0x01; + } + + #ifdef __NVIC_PRIO_BITS + { + /* Check the CMSIS configuration that defines the number of + * priority bits matches the number of priority bits actually queried + * from the hardware. */ + configASSERT( ( portMAX_PRIGROUP_BITS - ulMaxPRIGROUPValue ) == __NVIC_PRIO_BITS ); + } + #endif + + #ifdef configPRIO_BITS + { + /* Check the FreeRTOS configuration that defines the number of + * priority bits matches the number of priority bits actually queried + * from the hardware. */ + configASSERT( ( portMAX_PRIGROUP_BITS - ulMaxPRIGROUPValue ) == configPRIO_BITS ); + } + #endif + + /* Shift the priority group value back to its position within the AIRCR + * register. */ + ulMaxPRIGROUPValue <<= portPRIGROUP_SHIFT; + ulMaxPRIGROUPValue &= portPRIORITY_GROUP_MASK; + + /* Restore the clobbered interrupt priority register to its original + * value. */ + *pucFirstUserPriorityRegister = ulOriginalPriority; + } + #endif /* configASSERT_DEFINED */ +``` + +See also these pages: +- https://www.freertos.org/RTOS-Cortex-M3-M4.html +- https://www.freertos.org/freertos-on-qemu-mps2-an385-model.html diff --git a/results/classifier/zero-shot/108/none/1123975 b/results/classifier/zero-shot/108/none/1123975 new file mode 100644 index 000000000..eba07f1f0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1123975 @@ -0,0 +1,99 @@ +other: 0.474 +permissions: 0.366 +debug: 0.342 +semantic: 0.341 +graphic: 0.341 +device: 0.268 +KVM: 0.243 +PID: 0.237 +socket: 0.237 +performance: 0.213 +network: 0.193 +vnc: 0.192 +boot: 0.184 +files: 0.171 + +QEmu 1.3+ cannot restore a 1.1- live snapshot made in qemu-kvm + +I have upgraded to QEmu 1.3.90 (Debian 1.4.0~rc0+dfsg-1exp) but now when I try to restore a live snapshot made in QEmu 1.1.2 (Debian 1.1.2+dfsg-5) I get the following message: + +virsh # snapshot-revert fgtbbuild wtb +error: operation failed: Error -22 while loading VM state + +I have test VMs with live snapshots coreresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu. + + +ipxe-qemu 1.0.0+git-20120202.f6840ba-3 +qemu 1.4.0~rc0+dfsg-1exp +qemu-keymaps 1.4.0~rc0+dfsg-1exp +qemu-kvm 1.4.0~rc0+dfsg-1exp +qemu-system 1.4.0~rc0+dfsg-1exp +qemu-system-arm 1.4.0~rc0+dfsg-1exp +qemu-system-common 1.4.0~rc0+dfsg-1exp +qemu-system-mips 1.4.0~rc0+dfsg-1exp +qemu-system-misc 1.4.0~rc0+dfsg-1exp +qemu-system-ppc 1.4.0~rc0+dfsg-1exp +qemu-system-sparc 1.4.0~rc0+dfsg-1exp +qemu-system-x86 1.4.0~rc0+dfsg-1exp +qemu-user 1.4.0~rc0+dfsg-1exp +qemu-utils 1.4.0~rc0+dfsg-1exp +libvirt-bin 1.0.2-1 +libvirt-dev 1.0.2-1 +libvirt-doc 1.0.2-1 +libvirt-glib-1.0-0 0.1.2-1 +libvirt0 1.0.2-1 +libvirtodbc0 6.1.4+dfsg1-5 + +This sounds pretty much like a prob with video ram size. In 1.1.x, we had video ram of 8Mb, in 1.3 it is 16Mb... should this be a problem, to come from smaller to larger size? + +Besides that, debian uses almost unmodified qemu, so the same prob should exist for upstream qemu too. + +But at any rate, I never recommended any sort of cross-version migration as in practice, despite countless efforts spent to make it to work, it almost always does NOT work. + +Thanks, + +/mjt + +And one more thing -- from what to what are you trying to migrate? I see you have qemu-kvm installed too, -- were you using it previously? Note that qemu-kvm 1.1 had the same video ram size = 16Mb as current qemu have. But my cross-version migration comment stays and in this case it becomes even stronger. + +> And one more thing -- from what to what are you trying to migrate? + +I believe kvm is being used in both cases, though the command is different with QEmu 1.3.90. I have redone tests where I kept libvirt set to 1.0.2 and only switched between QEmu 1.1.2 and 1.3.90 to minimize the changes. So here the only difference is 'apt-get install -t experimental qemu'. + +Here is what 'ps aux' shows me: + +libvirt 1.0.2-2 + QEmu 1.1.2 + +127 12841 92.7 4.6 1078272 189128 ? Sl 00:45 10:46 /usr/bin/kvm -name fgtbwinxp -S -M pc-1.1 -cpu Penryn,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 768 -smp 2,sockets=2,cores=1,threads=1 -uuid e624f2c9-80fd-26c7-a38a-0f0e49b6b719 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbwinxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbwinxp.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive 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=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:c7:0e:97,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 -vga vmware -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=0x5 -loadvm wtb + +With libvirt 1.0.2-2 + QEmu 1.3.90 +127 18709 39.7 0.8 1075732 35304 ? Sl 01:39 0:05 qemu-system-x86_64 -machine accel=kvm:tcg -name fgtbwinxp -S -M pc-1.1 -cpu Penryn,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 768 -smp 2,sockets=2,cores=1,threads=1 -uuid e624f2c9-80fd-26c7-a38a-0f0e49b6b719 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbwinxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbwinxp.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive 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=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:c7:0e:97,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 -vga vmware -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=0x5 -loadvm wtb + + +There's a wrinkle I missed in my original report: the behavior is different depending on whether the VM is already running or not. + +$ virsh --connect qemu:///system destroy fgtbwinxp +$ virsh --connect qemu:///system snapshot-revert fgtbwinxp wtb;echo $? +0 +# This command looks like it succeeds but in fact I see the VM booting Windows. So either the live state was not restored at all or it crashed before virt-viewer could connect. +$ virsh --connect qemu:///system snapshot-revert fgtbwinxp wtb;echo $? +error: operation failed: Error -22 while loading VM state +1 + + +> But at any rate, I never recommended any sort of cross-version migration +> as in practice, despite countless efforts spent to make it to work, it +> almost always does NOT work. + +Ouch. I expect to end up with about 50 live snapshots. It would be pretty annoying to have to redo all of them every time I upgrade QEmu / KVM :-( + +Ok, so this is migration from qemu-kvm 1.1 to qemu 1.3. This officially does not work because the two uses different memory layout. + +There is a way to make this work from old qemu-kvm to new qemu, by patching new qemu, but this introduces incompatibilities in other areas. + +Hopefully there will be no more "major" transitions like this in the future (I mean from qemu-kvm to qemu), so there's a chance that snapshots made with 1.3 and up will be forward-compatible. + +While this bugreport is filed with debian versions in mind, we in debian especially did not apply any changes to upstream qemu in this area, -- as history shows, any attempt to "fix" this "downstream" only makes things worse. + +I think we can close this ticket nowdays - as Michael mentioned in comment #4, migration between qemu-kvm and qemu was not supported, and the mentioned versions are pretty much outdated now anyway. + diff --git a/results/classifier/zero-shot/108/none/113 b/results/classifier/zero-shot/108/none/113 new file mode 100644 index 000000000..e7aa1ff80 --- /dev/null +++ b/results/classifier/zero-shot/108/none/113 @@ -0,0 +1,16 @@ +graphic: 0.331 +permissions: 0.274 +semantic: 0.237 +vnc: 0.190 +device: 0.175 +debug: 0.153 +other: 0.096 +PID: 0.075 +network: 0.067 +KVM: 0.050 +performance: 0.043 +socket: 0.041 +boot: 0.027 +files: 0.020 + +missing manpage for bridge.conf diff --git a/results/classifier/zero-shot/108/none/1130 b/results/classifier/zero-shot/108/none/1130 new file mode 100644 index 000000000..d5e63cec1 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1130 @@ -0,0 +1,44 @@ +device: 0.532 +graphic: 0.467 +boot: 0.449 +socket: 0.412 +network: 0.385 +permissions: 0.382 +vnc: 0.364 +performance: 0.342 +PID: 0.316 +semantic: 0.220 +KVM: 0.184 +files: 0.127 +debug: 0.098 +other: 0.056 + +error on run qemu-system-aarch64 -icount shift=1,align=off,sleep=on -smp 2 +Description of problem: +This issue happen with the most recent version. +* Compile parameters: +``` +./configure --target-list=aarch64-softmmu --prefix=pwd/release --disable-werror --enable-lto --enable-capstone --enable-system --enable-fdt --disable-xen --disable-kvm --enable-plugins +``` +* run： +``` +qemu-system-aarch64 -nographic -machine virt -cpu cortex-a57 -icount shift=1,align=off,sleep=on -smp 2 -vnc :2 -m 4080 -kernel /home/yuzy/mywork/linux/linux-5.15.30/arch/arm64/boot/Image.gz -initrd /home/yuzy/mywork/build/rootfs.cpio.gz +``` +* error occurred： +``` +** +ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +Aborted (core dumped) +``` +Steps to reproduce: +1. run qemu-system-aarch64 -machine virt -cpu cortex-a57 -icount shift=1,align=off,sleep=on -smp 2 -m 4080 -kernel Image.gz -initrd rootfs.cpio.gz +2. it will assertion failed: (qemu_mutex_iothread_locked()) +Additional information: +The following two situations are good： +``` +qemu-system-aarch64 -machine virt -cpu cortex-a57 -icount shift=1,align=off,sleep=on -smp 1 -m 4080 -kernel Image.gz -initrd rootfs.cpio.gz +``` +``` +qemu-system-aarch64 -machine virt -cpu cortex-a57 -smp 2 -m 4080 -kernel Image.gz -initrd rootfs.cpio.gz +``` +I assume the issues are: gic diff --git a/results/classifier/zero-shot/108/none/1141 b/results/classifier/zero-shot/108/none/1141 new file mode 100644 index 000000000..32864e385 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1141 @@ -0,0 +1,25 @@ +graphic: 0.243 +performance: 0.160 +device: 0.091 +files: 0.082 +other: 0.081 +permissions: 0.066 +semantic: 0.065 +PID: 0.035 +boot: 0.025 +debug: 0.023 +network: 0.015 +socket: 0.015 +vnc: 0.014 +KVM: 0.002 + +virtio-gpu-gl-pci not working with arm/aarch64 +Description of problem: +Since migration to using virtio-gpu-gl-pci instead of virtio-gpu-pci (commit 17cdac0b51bc4ad7a68c3e5e0b1718729b74d512, used git-bisect to find the problem) my arm guests fail to load. If I use -device virtio-gpu-gl-pci, I don't get any image on the virtual guest screen. If I use -device virtio-gpu-pci, I can boot the guest and get the image, but GL acceleration is not working. Changing sdl to gtk doesn't help. +Steps to reproduce: +1. Download debian netinstall boot iso for arm (https://cdimage.debian.org/debian-cd/current/armhf/iso-cd/debian-11.4.0-armhf-netinst.iso) +2. Copy edk2-arm-code.fd and edk2-arm-vars.fd files from build dir. +3. Run command line ```qemu-system-arm -machine virt -m 512 -cdrom debian.iso -device virtio-gpu-gl-pci -display sdl,gl=on,show-cursor=on -pflash edk2-arm-code.fd -pflash edk2-arm-vars.fd```, get a black virtual screen. +4. Run command line ```qemu-system-arm -machine virt -m 512 -cdrom debian.iso -device virtio-gpu-pci -display sdl,gl=on,show-cursor=on -pflash edk2-arm-code.fd -pflash edk2-arm-vars.fd```, get an image on the virtual screen. +Additional information: +I have an x86_64 guest which uses virgl, and it runs fine after 17cdac0b51bc4ad7a68c3e5e0b1718729b74d512 with only changing virtio-gpu-pci to virtio-gpu-gl-pci diff --git a/results/classifier/zero-shot/108/none/1161 b/results/classifier/zero-shot/108/none/1161 new file mode 100644 index 000000000..4e619788c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1161 @@ -0,0 +1,16 @@ +performance: 0.496 +device: 0.455 +vnc: 0.365 +graphic: 0.359 +boot: 0.289 +files: 0.205 +network: 0.204 +semantic: 0.052 +other: 0.043 +PID: 0.035 +debug: 0.033 +socket: 0.028 +permissions: 0.016 +KVM: 0.008 + +revise docs/interop/virtio-balloon-stats.rst diff --git a/results/classifier/zero-shot/108/none/1163034 b/results/classifier/zero-shot/108/none/1163034 new file mode 100644 index 000000000..da35bcbb8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1163034 @@ -0,0 +1,61 @@ +device: 0.340 +socket: 0.280 +boot: 0.262 +performance: 0.246 +network: 0.236 +other: 0.219 +permissions: 0.217 +PID: 0.205 +debug: 0.205 +files: 0.165 +semantic: 0.147 +graphic: 0.133 +vnc: 0.102 +KVM: 0.031 + +linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) + +Please look at +https://code.launchpad.net/~costamagnagianfranco/+archive/costamagnagianfranco-ppa/+packages +and +https://code.launchpad.net/~costamagnagianfranco/+archive/costamagnagianfranco-ppa/+build/4457434 + +I cannot make gnutls28 build on armhf, I suspect a builder problem + +configure tries to check how printf behaves when it runs out of memory. I've attached a cut-down version of the code that reproduces the hang in qemu-arm-static, but works on real hardware. It uses a SIGSEGV handler, which is probably relevant. + +I've tested with qemu-arm-static 1.4.0-2013.02+git63+20130225+79aa792-0linaro1 and 1.4.0+dfsg-1expubuntu4. + +Anyway even if you disable this check you will find another unsupported syscall bug... :( + +Actually, assuming the guest ARM glibc doesn't have the printf() bug the code is testing for, we shouldn't take the SIGSEGV anyway, so that's a red herring. The actual problem here is the setrlimit(). + +The conftest.c test case works by using rlimit to limit the address space. This generally doesn't work on QEMU because we just pass the rlimit syscall through to the host, and end up limiting not just the guest program but also QEMU itself. QEMU doesn't expect its own allocations to fail and typically dies in confusing ways as a result. (Sometimes we do check allocations and call abort(), which then under linux-user doesn't work properly because we treat the resulting signal as if it were caused by the guest and not by QEMU's own code; IIRC we end up hanging in that situation.) In this particular instance we segfault in tb_alloc_page() because it doesn't check that page_find_alloc() didn't return NULL. + +[Confirmed by running qemu-arm under gdb.] + +Fixing this would require us to implement the address space rlimits entirely in QEMU by keeping track of how much memory we've handed the guest so we can fail mmap() etc. That is probably relatively speaking fairly tractable, though it's not a five minute job. + +Unsupported syscall bugs are usually easy fixes, incidentally (though occasionally they are nasty); also often QEMU will warn but things will continue OK because the guest libc/userspace supports fallback code for when a native kernel hasn't yet implemented the new syscall. + + +I'm referring to bug 1042388, I din't know about the fallback on this, but I have to say it doesn't work since apt exits and fails when encounters this call, maybe the fallback has some problems? + +Regarding bug 1042388, those are the posix timer syscalls, and I guess they've just been around long enough that apt expects them to exist. Anyway, we should just implement them in QEMU. + + +This will come in when implemented upstream. + +It's been a while since the last change to this ticket ... Has this ever been implemented? + +This bug is still valid, yes. + + + +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/95 + + diff --git a/results/classifier/zero-shot/108/none/1168733 b/results/classifier/zero-shot/108/none/1168733 new file mode 100644 index 000000000..2c56978dc --- /dev/null +++ b/results/classifier/zero-shot/108/none/1168733 @@ -0,0 +1,30 @@ +graphic: 0.485 +semantic: 0.326 +other: 0.093 +device: 0.091 +network: 0.086 +socket: 0.058 +files: 0.049 +vnc: 0.041 +PID: 0.033 +permissions: 0.030 +debug: 0.028 +performance: 0.023 +KVM: 0.014 +boot: 0.011 + +reserved identifier violation + +I would like to point out that identifiers like the following do not fit to the expected naming convention of the C language standard. +- __COMMAND_H__ + http://git.qemu.org/?p=qemu.git;a=blob;f=cmd.h;hb=64b85a8f2359ca3a995499afaf3c87d8e036e030#l17 + +- _QEMU_OPTIONS_H_ + http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-options.h;hb=77bd1119ba43dbd0e73014037a08f8b49136bf6f#l28 + +Would you like to adjust your selection for unique names? +https://www.securecoding.cert.org/confluence/display/seccode/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier#DCL37-C.Donotdeclareordefineareservedidentifier-NoncompliantCodeExample%28HeaderGuard%29 + +This has recently been cleaned up here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2a6a4076e117113eb + diff --git a/results/classifier/zero-shot/108/none/1178107 b/results/classifier/zero-shot/108/none/1178107 new file mode 100644 index 000000000..033976cc1 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1178107 @@ -0,0 +1,39 @@ +other: 0.545 +device: 0.533 +graphic: 0.511 +performance: 0.482 +semantic: 0.413 +socket: 0.253 +debug: 0.236 +boot: 0.211 +vnc: 0.199 +PID: 0.177 +network: 0.164 +files: 0.132 +permissions: 0.041 +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/zero-shot/108/none/1186935 b/results/classifier/zero-shot/108/none/1186935 new file mode 100644 index 000000000..4b164e02e --- /dev/null +++ b/results/classifier/zero-shot/108/none/1186935 @@ -0,0 +1,48 @@ +graphic: 0.513 +device: 0.334 +semantic: 0.288 +other: 0.114 +socket: 0.058 +performance: 0.056 +PID: 0.053 +boot: 0.052 +debug: 0.051 +network: 0.032 +vnc: 0.022 +permissions: 0.022 +files: 0.015 +KVM: 0.006 + +[1.5] QEMU monitor gets overlapped by GTK menu bar + +The QEMU minitor gets partially hidden by the menu bar which was introduced in QEMU version 1.5.0. + +Steps to reproduce: + + 1. Run `qemu-system-x86_64` + 2. Press Ctrl + Alt + 2 (or use the menu bar) + 3. Observe that the monitor output is partially shown, without the "compat_monitor0 console" and "QEMU 1.5.0 monitor - type 'help' for more information" lines. + +Attached is a screenshot of `qemu-system-x86_64` and `qemu-system-x86_64 -display sdl`. + +Version: 1.5.0 +Distribution: Arch Linux 64-bit + + + +What version of gtk is this? + +gtk 3.8.2 + +This seems to be a bug when building against gtk3. + +When building against gtk 3.8.2: +- monitor text gets hidden behind menu bar +- a bar appears on the bottom, growing as the window is resized. When the contents overflows (a scrollbar appears), this bar is gone. + +Building against gtk 2.24.18 / vte 0.28.2 resolves the above issues. + +Can you still reproduce this issue with the latest version of QEMU / the latest version of gtk? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1190525 b/results/classifier/zero-shot/108/none/1190525 new file mode 100644 index 000000000..48be850f3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1190525 @@ -0,0 +1,76 @@ +device: 0.498 +other: 0.353 +PID: 0.349 +performance: 0.336 +semantic: 0.312 +graphic: 0.295 +socket: 0.275 +boot: 0.233 +permissions: 0.210 +network: 0.210 +files: 0.205 +vnc: 0.186 +KVM: 0.124 +debug: 0.114 + +fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk + +RHEL guest shows the partittions even after the removal of scsi disk: +fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk. + +Guest details: +------------------- +Kernel : 2.6.32-358 + + +Host Details : + +Upstream Kernel, Qemu, Libvirt and virt-manager +--------------------------------------------------------------------- + +kernel version : 3.9.0+ +qemu version : QEMU emulator version 1.5.0 +libvirt version : 1.0.5 +virt-install : 0.600.3 + + +Steps to reproduce the issue: + +I. Add the SCSI disk through the virt-manager. +2. Create the partition using fdisk (eg: /dev/sbb) +3. Create a filesystem and format using mkfs.ext3 or mkfs.ext4 +4. Remove the scsi disk through the virt-manager. +5. Again run the fdisk /dev/sdb, the guests still shows the partition even after the removal of the disk. + +This issue is not seen with virt-io disk. + +This issue is also reproducible without even creating the partitions. + +Expected Result: + +The output of fdisk /dev/sd* should not show the enties after the removal of scsi disks + + + +On Thu, Jun 13, 2013 at 09:33:37AM -0000, chandrashekar shastri wrote: +> Steps to reproduce the issue: +> +> I. Add the SCSI disk through the virt-manager. +> 2. Create the partition using fdisk (eg: /dev/sbb) +> 3. Create a filesystem and format using mkfs.ext3 or mkfs.ext4 +> 4. Remove the scsi disk through the virt-manager. +> 5. Again run the fdisk /dev/sdb, the guests still shows the partition even after the removal of the disk. + +Which emulated SCSI controller are you using? Recent virtio-scsi gets +notified when LUNs are removed but you may have old guest drivers. + +If you want to report this as a QEMU bug, please give QEMU commands, not +virt-manager commands. If you cannot use QEMU directly, please work +with the virt-manager or libvirt community before filing a QEMU bug so +the necessary QEMU-level details can be provided by them. + +Stefan + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1191326 b/results/classifier/zero-shot/108/none/1191326 new file mode 100644 index 000000000..b906fb9e7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1191326 @@ -0,0 +1,244 @@ +KVM: 0.538 +device: 0.453 +graphic: 0.437 +permissions: 0.384 +other: 0.379 +vnc: 0.379 +semantic: 0.356 +performance: 0.334 +debug: 0.328 +PID: 0.326 +boot: 0.322 +network: 0.308 +socket: 0.226 +files: 0.142 + +QNX 4 doesn't boot on qemu >= 1.3 + + +I am using virtual machine with QNX4 operating system installed on it. I updated my qemu from version +to newer and QNX4 doesn't start any more. All is ok on version 1.2 but when I try to use any newer version +(1.3, 1.4, 1.5) QNX4 doesn't boot. I tried on windows and linux ubuntu hosts - effects are the same. + +When virtual machine boots qnx bootloader loads and starts operating system. In the next step +qnx starts its ide driver, which detects qemu harddisk and cdrom. Problem starts when operating system +tries mount partition - an error occur and qnx stop booting procedure: + +mount -p "No bios signature in partition sector on /dev/hd0" + +I have tried install qnx from cdrom but it seems that there is the same problem. QNX installer boot from +cdrom, detects hard disk and cdrom, but cdrom can't be mounted in the next step of installation procedure. + +with qemu 1.6 is even worse - qemu crash every time when QNX detects hard disk + +Please use git-bisect to find out which change between 1.2.0 and 1.3.0 broke things for you. + +problem appeared in this commit: + +commit b90600eed3c0efe5f3260853c873caf51c0677b1 +Author: Avi Kivity <email address hidden> +Date: Wed Oct 3 16:42:37 2012 +0200 + + dma: make dma access its own address space + + Instead of accessing the cpu address space, use an address space + configured by the caller. + + Eventually all dma functionality will be folded into AddressSpace, + but we have to start from something. + + Reviewed-by: Anthony Liguori <email address hidden> + Signed-off-by: Avi Kivity <email address hidden> + +Output from valgrind running latest qemu downloaded from git. Qemu crashed of course. +If I can check something more, please let me know. + +==29109== Memcheck, a memory error detector +==29109== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. +==29109== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info +==29109== Command: qemu-system-i386 -no-kvm -hda /home/jq/QNX4.vmdk +==29109== Parent PID: 15280 +==29109== +==29109== Invalid write of size 8 +==29109== at 0x4C2CD8D: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4DF292: iov_from_buf (iov.c:37) +==29109== by 0x4E01B8: qemu_iovec_from_buf (iov.c:374) +==29109== by 0x1A0CA6: bdrv_aio_bh_cb (block.c:3820) +==29109== by 0x186CEB: aio_bh_poll (async.c:81) +==29109== by 0x18693D: aio_poll (aio-posix.c:188) +==29109== by 0x1870FA: aio_ctx_dispatch (async.c:205) +==29109== by 0x5081AB4: g_main_context_dispatch (gmain.c:2715) +==29109== by 0x3235CE: glib_pollfds_poll (main-loop.c:189) +==29109== by 0x3236C2: os_host_main_loop_wait (main-loop.c:234) +==29109== by 0x32379A: main_loop_wait (main-loop.c:484) +==29109== by 0x3B0776: main_loop (vl.c:2090) +==29109== Address 0x157c8ff8 is not stack'd, malloc'd or (recently) free'd +==29109== +==29109== Invalid read of size 4 +==29109== at 0x3C4B85: ldl_p (bswap.h:262) +==29109== by 0x3C4CC6: ldl_le_p (bswap.h:295) +==29109== by 0x3CAAC2: address_space_rw (exec.c:1953) +==29109== by 0x3CAE0C: address_space_write (exec.c:2021) +==29109== by 0x3CB570: address_space_unmap (exec.c:2230) +==29109== by 0x1EF736: dma_memory_unmap (dma.h:146) +==29109== by 0x1EFCBD: dma_bdrv_unmap (dma-helpers.c:108) +==29109== by 0x1EFE35: dma_bdrv_cb (dma-helpers.c:146) +==29109== by 0x1A0FE0: bdrv_co_em_bh (block.c:3901) +==29109== by 0x186CEB: aio_bh_poll (async.c:81) +==29109== by 0x18693D: aio_poll (aio-posix.c:188) +==29109== by 0x1870FA: aio_ctx_dispatch (async.c:205) +==29109== Address 0x157ba000 is 0 bytes after a block of size 4,096 alloc'd +==29109== at 0x4C29CD5: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4C29D2E: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4DA0AB: qemu_memalign (oslib-posix.c:90) +==29109== by 0x3CB322: address_space_map (exec.c:2162) +==29109== by 0x1EF6BE: dma_memory_map (dma.h:137) +==29109== by 0x1EFEEF: dma_bdrv_cb (dma-helpers.c:156) +==29109== by 0x1F0205: dma_bdrv_io (dma-helpers.c:219) +==29109== by 0x1F027A: dma_bdrv_read (dma-helpers.c:228) +==29109== by 0x2724C4: ide_dma_cb (core.c:676) +==29109== by 0x278AC2: bmdma_cmd_writeb (pci.c:324) +==29109== by 0x2792AA: bmdma_write (piix.c:76) +==29109== by 0x43535C: memory_region_write_accessor (memory.c:440) +==29109== + +valgrind: m_mallocfree.c:266 (mk_plain_bszB): Assertion 'bszB != 0' failed. +valgrind: This is probably caused by your program erroneously writing past the +end of a heap block and corrupting heap metadata. If you fix any +invalid writes reported by Memcheck, this assertion failure will +probably go away. Please try that before reporting this as a bug. + +==29109== at 0x3804C6CF: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3804C812: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x38000883: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x38057FB1: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x38058962: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x380212DC: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3802158F: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3808F1DB: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3809E68C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable +==29109== at 0x4C29CD5: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4C29D2E: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4DA0AB: qemu_memalign (oslib-posix.c:90) +==29109== by 0x1A2192: qemu_blockalign (block.c:4375) +==29109== by 0x1A0D92: bdrv_aio_rw_vector (block.c:3842) +==29109== by 0x1A0EB6: bdrv_aio_readv_em (block.c:3861) +==29109== by 0x1A169A: bdrv_co_io_em (block.c:4068) +==29109== by 0x1A172B: bdrv_co_readv_em (block.c:4085) +==29109== by 0x19D921: bdrv_co_do_readv (block.c:2574) +==29109== by 0x1A1091: bdrv_co_do_rw (block.c:3918) +==29109== by 0x1E7776: coroutine_trampoline (coroutine-ucontext.c:118) +==29109== by 0x5F3264F: ??? (in /lib/x86_64-linux-gnu/libc-2.15.so) +==29109== by 0x7FEFFC5CF: ??? + +Thread 2: status = VgTs_WaitSys +==29109== at 0x5CDB0C1: sem_timedwait (sem_timedwait.S:102) +==29109== by 0x4DAD2A: qemu_sem_timedwait (qemu-thread-posix.c:238) +==29109== by 0x387F22: worker_thread (thread-pool.c:97) +==29109== by 0x5CD4E99: start_thread (pthread_create.c:308) +==29109== by 0x5FDDCCC: clone (clone.S:112) + +Thread 3: status = VgTs_WaitSys +==29109== at 0x5CDB89C: __lll_lock_wait (lowlevellock.S:132) +==29109== by 0x5CDE2B7: _L_cond_lock_874 (pthread_mutex_lock.c:483) +==29109== by 0x5CDE086: __pthread_mutex_cond_lock (pthread_mutex_lock.c:61) +==29109== by 0x5CD8E17: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.S:236) +==29109== by 0x4DAB68: qemu_cond_wait (qemu-thread-posix.c:116) +==29109== by 0x3BE13E: qemu_tcg_wait_io_event (cpus.c:760) +==29109== by 0x3BE588: qemu_tcg_cpu_thread_fn (cpus.c:891) +==29109== by 0x5CD4E99: start_thread (pthread_create.c:308) +==29109== by 0x5FDDCCC: clone (clone.S:112) + +Thread 4: status = VgTs_WaitSys +==29109== at 0x5CD8D84: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.S:162) +==29109== by 0x4DAB68: qemu_cond_wait (qemu-thread-posix.c:116) +==29109== by 0x3A38CD: vnc_worker_thread_loop (vnc-jobs.c:222) +==29109== by 0x3A3DF6: vnc_worker_thread (vnc-jobs.c:318) +==29109== by 0x5CD4E99: start_thread (pthread_create.c:308) +==29109== by 0x5FDDCCC: clone (clone.S:112) + + +On Linux hosts are you using KVM? Does it make any difference? + +Is there a freely downloadable image that we can use for debugging? + +Thanks, + +Paolo + +KVM doesnt make any difference. + + +I am also experiencing this problem QNX 4.25 images that were created under 1.0 no longer work when I've upgraded to 2.0 or 2.1 qemu. + +The error message that I receive is the same. The problem is with the virtual disk driver, it performs the initial boat loader, then when the OS goes to load the file system it fails. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + +I've just tried to launch QNX 4.25 ISO bootdisk on qemu-system-x86_64 built from current git. +QEMU screen is skewed (see on screenshot). I tried all different options in -vga key - all the same. + +This is still a problem with QEMU 2.11. + +Note that the problem in #10 is unrelated to the issue (though GUI works for with the the demo floppy). The problem mentioned in this bug is related to a QNX that is already installed to a disk. Unfortunately the QNX demo floppy that was once free and which can be still found on the internet does not allow installation to disk, so it can't be used to reproduce the bug. + +At work we still maintain an application for QNX 4.25 so I can help debugging it, but I don't know where to start. Currently we use VirtualBox and VMware, but I personally would prefer QEMU much more. + +Please let me know if there is any way how I could help to sort this issue out. + +I wonder - would be a record using rr of any help? I can create record for QEMU 1.2.0 where it works and on current QEMU. + +Also, I did a bit of debugging myself around the DMA code as per comment #3 it was introduced in a commit that changed some of the DMA. What I did was that I added some debug printfs [1] to dma_memory_rw() to QEMU 1.2.0 and to QEMU 2.11.1. + +I noticed on thing - there is a big difference between writes between the two versions. +Because this stuff is completely outside my knowledge, I don't know whether this is important or not, but better more information that not enough. For recent versions of QEMU I see a few 16 B writes from address 0x6d10 and addresses close to it which contain some data. Immediately after that there is a ton of 8B writes from addresses starting at 0x102004 which contain zeros only. On the other hand, the QEMU 1.2.0 is missing the initial 16B writes, but then there's even more 8B writes from addresses around 0x102004 which contain some data instead of zeros like in the current version. + +[1] the printf looks like this: + +printf("DEBUG: DMA %s at address %lx %lu bytes: ", ((dir == DMA_DIRECTION_FROM_DEVICE) ? "read" : "write"), addr, len); + +Hi, + +I had the same problem, and maybe it can help. I wrote my own toy OS with a PATA / IDE driver back in 2012 using older version of QEMU and everything worked fine. These days, I tried that on a recent version (2.5) and it failed with exactly the same behaviour - lots of zeros being written during a DMA transfer. + +After some research, I found that the behaviour that was changed with 1.3 is that the bus master configuration bit (bit 2 of the PCI command register) is now emulated, and my driver did not set this bit. Apparently, the BIOS does not set it either, so it was off and the DMA transfer silently failed and only wrote zeros. + +So I added some code to my init routine that sets this bit, and voila - it worked. I have tried 1.2, 1.3 and 2.5.0 and this works with all of them. + +I do not know the internals of QNX, but I learned that apparently also Linux did not set this bit in older version, so it might very well be that QNX does not set it either and this is the issue. + +@Christiat: thank you so much, you are right! I put together a quick hack[1] to seabios to forcefully enable bus master bit on ata device and QNX booted! + +[1] I just added an unconditional call to the pci_enable_busmaster(pci); to the init_pciata() function in ata.c + +It turns out modifying code is not needed at all. The only thing that is needed is to configure SeaBIOS with CONFIG_ATA_DMA=y. + +So the steps needed to make QNX 4 work on current QEMU are +1. Download SeaBIOS source and make sure the configuration has CONFIG_ATA_DMA=y set +2. Build SeaBIOS +3. Run qemu such as "qemu-system-i386 -bios /path/to/seabios/bios.bin -hda qnxdisk ..." + +qemu git master has a prebuilt seabios with CONFIG_ATA_DMA=y now. + +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/zero-shot/108/none/1200212 b/results/classifier/zero-shot/108/none/1200212 new file mode 100644 index 000000000..89018399b --- /dev/null +++ b/results/classifier/zero-shot/108/none/1200212 @@ -0,0 +1,41 @@ +device: 0.512 +graphic: 0.488 +semantic: 0.427 +network: 0.379 +socket: 0.344 +PID: 0.326 +performance: 0.303 +other: 0.263 +boot: 0.202 +vnc: 0.200 +permissions: 0.178 +files: 0.150 +debug: 0.090 +KVM: 0.082 + +qemu-system-arm aborts in lsi_soft_reset + +Qemu compiled from master branch (fetched on 11th Jul 2013, qemu-system-arm -version prints "QEMU emulator version 1.5.50, Copyright (c) 2003-2008 Fabrice Bellard") running on OSX 10.6.8 crashes during Debian 7.1 netboot installation with error: "Assertion failed: (QTAILQ_EMPTY(&s->queue)), function lsi_soft_reset, file hw/scsi/lsi53c895a.c, line 351." + +Steps to reproduce: + +1. Get kernel and initrd from http://ftp.debian.org/debian/dists/Debian7.1/main/installer-armel/20130613/images/versatile/netboot/ . +2. Create a hard disk image with qemu-img: qemu-img create -f qcow2 debian.qcow2 2G. +3. Run arm-softmmu/qemu-system-arm -M versatilepb -kernel vmlinuz-3.2.0-4-versatile \ + -initrd initrd-3.2.0-4-versatile-netboot -drive file=debian.qcow2,index=0,if=scsi,media=disk \ + -append "console=ttyAMA0" -nographic -net user,hostfwd=tcp:127.0.0.1:22080-:80,vlan=0 \ + -net nic,vlan=0 -smp 1,cores=4 + +The installation should proceed past partition setup and start downloading packages onto hard disk. After several tries I've never got past 31% with the package downloads before getting Abort trap with "Assertion failed: (QTAILQ_EMPTY(&s->queue)), function lsi_soft_reset, file hw/scsi/lsi53c895a.c, line 351." message. + +This is (very likely) related to this /old/ bug: + +http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg02521.html + +Could you try the patch at http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg00248.html ? + + +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/zero-shot/108/none/1204 b/results/classifier/zero-shot/108/none/1204 new file mode 100644 index 000000000..ff87d0cfd --- /dev/null +++ b/results/classifier/zero-shot/108/none/1204 @@ -0,0 +1,44 @@ +device: 0.406 +graphic: 0.397 +semantic: 0.357 +network: 0.356 +socket: 0.345 +vnc: 0.306 +performance: 0.295 +PID: 0.251 +debug: 0.208 +other: 0.165 +permissions: 0.165 +boot: 0.147 +KVM: 0.125 +files: 0.113 + +AArch64 unaligned accesses are allowed by QEMU when SCTLR_EL3.A is 0, but SCTLR_EL3.M is also 0 +Description of problem: +As per the ARM ARM, when address translation is disabled and the access is not done from EL1/0 with HCR_EL2.DC set to 1, data accesses receive the 'Device-nGnRnE' memory attribute (D.8.2.10 The effects of disabling an address translation stage - DDi0487I.a, Page D8-5119). +Memory regions marked as Device do not support unaligned access. +Steps to reproduce: +Run the following snippet under EL3, and notice the last load instruction completes successfully (doesn't raise an alignment fault) +``` +.balign 8 +.global first_variable +first_variable: + .word 0x1 +.balign 4 +.global second_variable +second_variable: + .word 0x2 + +no_mmu_sctlr: .dword 0x0000000030C51834 + +.globl reproducer +reproducer: + ldr x1, no_mmu_sctlr // A=0,M=0 + msr sctlr_el3, x1 + dsb sy + isb + + ldr x0, =first_variable + ldr x1, [x0, #0] // Aligned - Success + ldr x1, [x0, #4] // Unaligned - Success??? (Should be failure) +``` diff --git a/results/classifier/zero-shot/108/none/1217339 b/results/classifier/zero-shot/108/none/1217339 new file mode 100644 index 000000000..8f0e1bf23 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1217339 @@ -0,0 +1,85 @@ +permissions: 0.589 +other: 0.534 +debug: 0.523 +graphic: 0.516 +semantic: 0.493 +device: 0.481 +PID: 0.464 +performance: 0.461 +network: 0.441 +files: 0.440 +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/zero-shot/108/none/1223467 b/results/classifier/zero-shot/108/none/1223467 new file mode 100644 index 000000000..5c3b6bbe9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1223467 @@ -0,0 +1,62 @@ +semantic: 0.445 +performance: 0.313 +device: 0.266 +PID: 0.249 +other: 0.228 +socket: 0.216 +permissions: 0.210 +graphic: 0.201 +debug: 0.173 +files: 0.165 +boot: 0.145 +network: 0.138 +vnc: 0.106 +KVM: 0.065 + +Unable to use USB as hda in Windows + +I built qemu 1.6.0 from source in MinGW (and all dependents not available with mingw-get) +The command line: +qemu-system-i386.exe -m 1024 -hda \\.\PhysicalDrive1 -L pc-bios +or +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L pc-bios +(or the *w.exe equivalents) +reports in stderr.txt: +qemu-system-i386.exe: -hda \\.\PhysicalDrive1: Block protocol 'host_device' doesn't support the option 'filename' +qemu-system-i386.exe: -hda \\.\PhysicalDrive1: could not open disk image \\.\PhysicalDrive1: Invalid argument + +I have also found this bug in 1.5 but not in 1.4 + +Some Help: +The code in Qemu is a bit beyond me at 1am, but I was able to determine the root cause seems to be that block.c is becoming confused about referring to a file but not having a file name. I have been able to work around this by changing line 860 of block.c from: "if (qdict_size(options) != 0) {" to "if (qdict_size(options) != 0 && !is_windows_drive(filename)) {" + +But I don't think this is a good solution (it is assuming that nothing else could be wrong), and I can't be sure that I'm not masking some real issue. + +FWIW; Build is on XP, but execution is on Win7. + +Thanks. + +I can confirm the same bug. I am not building from source, but rather using the unofficial Windows binaries linked to by Qemu. + +http://wiki.qemu.org/Links + +I'm running as Administrator on Win8.1 x86_64 + +qemu-system-i386.exe -L . -hda \\.\PhysicalDrive3 + +qemu-system-i386.exe: -hda \\.\PhysicalDrive3: Block protocol 'host_device' doesn't support the option 'filename' +qemu-system-i386.exe: -hda \\.\PhysicalDrive3: could not open disk image \\.\PhysicalDrive3: Invalid argument + +I see this error in the 1.51, 1.53, and 1.60 builds from a couple different sources + +PhysicalDrive3 is a USB device that's visible in the Windows Disk Management Snap-In. I see the activity light on the drive blink when running this command. + +I've found some older Qemu binaries from various random sources https://code.google.com/p/kqemu-portable-win/ and they seem to be able to access physical devices without issue, though they also seem to have other problems of their own... + +I think this has been fixed by commit 68dc0364, which was included in +qemu 1.7.0 and also backported to 1.6.1. Can you please try upgrading and +confirm whether it fixes the problem? + + +I found some newer Windows binaries at http://qemu.weilnetz.de/ and can confirm I do not see the issue any more. + diff --git a/results/classifier/zero-shot/108/none/1226531 b/results/classifier/zero-shot/108/none/1226531 new file mode 100644 index 000000000..6a1ac5978 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1226531 @@ -0,0 +1,75 @@ +permissions: 0.537 +PID: 0.481 +other: 0.453 +semantic: 0.449 +vnc: 0.398 +performance: 0.378 +graphic: 0.375 +device: 0.364 +network: 0.363 +socket: 0.350 +files: 0.347 +KVM: 0.341 +boot: 0.329 +debug: 0.314 + +Incorrect logic in ARMv7M interrupt handler + +On ARMv7M interrupts handlers will be called even if emulated code executes "cpsid i" instruction. + +Underlying cause described below: + +In cpu-exec.c:cpu_exec there is a block of code that determines if an interrupt should be raised or not: + + + /* ARMv7-M interrupt return works by loading a magic value + into the PC. On real hardware the load causes the + return to occur. The qemu implementation performs the + jump normally, then does the exception return when the + CPU tries to execute code at the magic address. + This will cause the magic PC value to be pushed to + the stack if an interrupt occurred at the wrong time. + We avoid this by disabling interrupts when + pc contains a magic address. */ + if (interrupt_request & CPU_INTERRUPT_HARD + && ((IS_M(env) && env->regs[15] < 0xfffffff0) + || !(env->uncached_cpsr & CPSR_I))) { + env->exception_index = EXCP_IRQ; + cc->do_interrupt(cpu); + next_tb = 0; + } + +I'm not convinced the logic is correct. +The logic for ARMv7M should be: + +If an interrupt is pending (interrupt_request & CPU_INTERRUPT_HARD) +AND +Interrupts are not disabled ( !(env->uncached_cpsr & CPSR_I) ) +AND +PC doesn't have a magic value (env->regs[15] < 0xfffffff0) + +The current logic seems fires the interrupt if interrupts are enabled OR the PC isn't magic, which is basically all the time. + +I'm not sure what the cleanest patch for this would be. + +On 17 September 2013 11:44, benno <email address hidden> wrote: +> I'm not convinced the logic is correct. + +It's not. There have been a few attempts by people to submit patches +to this though, but none of them have actually been sufficiently +convincing. See for instance +http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg04546.html + +If somebody produces a patch which comes with a good rationale +for its change (ie with reference to the architecture manual and to +what QEMU means when it sets "CPSR_I" on M profile) I'll apply +it. But because the v7M code is currently not really maintained and +v7M interrupts are complex I'm reluctant to apply patches which +only come with "seems to fix things for me" levels of justification. + +-- PMM + + +We finally fixed this longstanding ARMv7M emulation bug in the 2.10 release (by rewriting the NVIC handling entirely). + + diff --git a/results/classifier/zero-shot/108/none/1242 b/results/classifier/zero-shot/108/none/1242 new file mode 100644 index 000000000..74f874632 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1242 @@ -0,0 +1,16 @@ +performance: 0.544 +device: 0.508 +graphic: 0.410 +other: 0.227 +debug: 0.225 +files: 0.208 +permissions: 0.184 +semantic: 0.114 +PID: 0.092 +socket: 0.022 +vnc: 0.019 +network: 0.018 +boot: 0.011 +KVM: 0.006 + +unable to build in mac diff --git a/results/classifier/zero-shot/108/none/1242765 b/results/classifier/zero-shot/108/none/1242765 new file mode 100644 index 000000000..9cb8c002c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1242765 @@ -0,0 +1,91 @@ +semantic: 0.378 +graphic: 0.294 +PID: 0.287 +permissions: 0.279 +other: 0.273 +debug: 0.234 +performance: 0.216 +device: 0.169 +KVM: 0.169 +network: 0.161 +vnc: 0.143 +socket: 0.100 +files: 0.085 +boot: 0.083 + +USB passthrough to Windows 7 guest fails with error -110, hangs + +Description of problem: + +Using a Sandisk Cruzer Fit 16GB USB thumb drive. +Using virt-manager on Fedora 19 host, and Windows 7 32 bit guest. + +I set up a USB2 controller on Windows 7 guest in virt-manager. Windows sees the USB drive and can open the file manager and correctly show the files. I can copy a file from the thumb drive to the Fedora desktop, and then play the file on the desktop. However, any attempt to open a file directly on the thumb drive (example, play an MP3 using Windows Media Player) results in guest hang and host kernel messages: + + +Oct 19 21:15:35 localhost kernel: [187592.977839] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:40 localhost kernel: [187598.065274] usb 1-1.3: device descriptor read/all, error -110 +Oct 19 21:15:40 localhost kernel: [187598.138167] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:56 localhost kernel: [187613.218119] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.399275] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.573355] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:16 localhost kernel: [187633.587778] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.702244] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.876201] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:26 localhost kernel: [187643.890642] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.005071] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.106188] usb 1-1.3: USB disconnect, device number 13 +Oct 19 21:16:31 localhost kernel: [187649.178969] usb 1-1.3: new high-speed USB device number 14 using ehci-pci +Oct 19 21:16:47 localhost kernel: [187664.258945] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.440092] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.614194] usb 1-1.3: new high-speed USB device number 15 using ehci-pci +Oct 19 21:17:17 localhost kernel: [187694.694148] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187709.875297] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187710.049386] usb 1-1.3: new high-speed USB device number 16 using ehci-pci +Oct 19 21:17:37 localhost kernel: [187715.063803] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:17:41 localhost kernel: [187719.005453] usb 1-1.3: device descriptor read/8, error -71 + +After that -71 error, the thumb drive completely disappears from the host, as if it is powered down. + +I read that -110 is supposedly a power issue. I can play media files directly from the thumb drive on the host, so the power seems fine on the host. + + +How reproducible: +always + + +Steps to reproduce: +1. use virt-manager, create a Windows 7 32 bit guest +2. in virt-manager, set Controller USB to USB2 +3. on host, insert Sandisk Cruser Fit thumb drive FAT32 format, with an MP3 file on it +4. in virt-manager, add a USB passthrough device and assign it to thumb drive +5. boot Windows 7 guest +6. verify that Windows 7 can see the thumb drive +7. use Windows Media Player to play MP3 + +Actual results: +guest hangs, then host powers off thumb drive + +Expected results: +The MP3 file should play :) + + +Additional info: + +Fedora 19 + +Installed Packages +qemu-common.x86_64 2:1.4.2-11.fc19 @updates +qemu-guest-agent.x86_64 2:1.4.2-11.fc19 @updates +qemu-img.x86_64 2:1.4.2-11.fc19 @updates +qemu-kvm.x86_64 2:1.4.2-11.fc19 @updates +qemu-system-x86.x86_64 2:1.4.2-11.fc19 @updates +virt-manager.noarch 0.10.0-3.fc19 @updates +kernel.x86_64 3.11.1-200.fc19 @updates + +Can you still reproduce this problem with the latest version of QEMU, or could we close this ticket nowadays? + +You may close. It's since worked fine for me. + +Also the ticket is years old :D + diff --git a/results/classifier/zero-shot/108/none/1256432 b/results/classifier/zero-shot/108/none/1256432 new file mode 100644 index 000000000..e3048cfd7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1256432 @@ -0,0 +1,23 @@ +graphic: 0.123 +device: 0.104 +semantic: 0.054 +other: 0.044 +network: 0.035 +debug: 0.026 +socket: 0.023 +vnc: 0.016 +PID: 0.012 +files: 0.012 +boot: 0.012 +performance: 0.009 +permissions: 0.008 +KVM: 0.000 + +qemu mingw 32bit windows crash + +is it a known bug that in windows that even if you do ./configure --disable-coroutine-pool it still builds the coroutine stuff so when you try and run the build after its compiled it crashses? you have to actually edit config-host.mak and change the c flags around. + +Which QEMU version did you use? Can you still reproduce this with the latest release? + +Oh sorry this has been working fine consider this resolved. + diff --git a/results/classifier/zero-shot/108/none/1257099 b/results/classifier/zero-shot/108/none/1257099 new file mode 100644 index 000000000..a68b82a43 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1257099 @@ -0,0 +1,1194 @@ +other: 0.326 +KVM: 0.263 +debug: 0.261 +graphic: 0.260 +device: 0.250 +permissions: 0.250 +files: 0.243 +PID: 0.240 +boot: 0.239 +vnc: 0.238 +performance: 0.233 +semantic: 0.232 +socket: 0.228 +network: 0.226 + +QEMU fails to build on CentOS 5.10 with relocation R_X86_64_PC32 error + + lt LINK libcacard.la +/usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' can not be used when making a shared object; recompile with -fPIC +/usr/bin/ld: final link failed: Bad value +collect2: ld returned 1 exit status +make[4]: *** [libcacard.la] Error 1 +make[3]: *** [subdir-libcacard] Error 2 + +I have bisect'd this to: + +dcs-xen-53:~/qemu>git-bisect next +00c705fb92bc6e69e955aeac3614e05ca02feacd is the first bad commit +commit 00c705fb92bc6e69e955aeac3614e05ca02feacd +Author: Paolo Bonzini <email address hidden> +Date: Tue May 29 11:40:24 2012 +0200 + + build: libcacard Makefile cleanups + + Build vscclient from toplevel Makefile, limit usage of vpath. + + Signed-off-by: Paolo Bonzini <email address hidden> + +:100644 100644 a10005a22fe44a107dfec15106960612b43be71f 1d34b9539e9ba47fdb7028ad0569389fa48712b9 M Makefile +:100644 100644 ae3770a5f718742838844f9064be6a7153ac7469 74110dda7e38b8ddae47a53ad4cb6ecf48231fa0 M Makefile.objs +:100644 100644 3dfdf925fdc2c92239b7053a3d4e09687dcc2171 555894db4aa717f15cfc24093d838131f422fc78 M Makefile.target +:100755 100755 e50ad0bb8fc2e331562f3c09e605af6597a143b1 cd5e8b349c137f621d2e9dc516145bc650d977c0 M configure +:040000 040000 160d565b7e551c3248333c9e49f34edb7a30f5e0 008bc3fccda52f78accf9494539ba62bfb1621a0 M libcacard + +dcs-xen-53:~/qemu>git bisect log +git bisect start +# bad: [7457fe9541b5162f285454947448d553a5d5a531] Update version for v1.7.0-rc2 release +git bisect bad 7457fe9541b5162f285454947448d553a5d5a531 +# good: [ed7ec8400707fe42f4a0f40db2f2d5827ecea789] Merge remote-tracking branch 'bonzini/scsi.2' into staging +git bisect good ed7ec8400707fe42f4a0f40db2f2d5827ecea789 +# bad: [1d31fca470648ec66afd8743491bfb5846306341] qemu-barrier: Fix compilation on i386 hosts +git bisect bad 1d31fca470648ec66afd8743491bfb5846306341 +# good: [9de36b1a7cf61aa8be365f13c81668b3e19fbc7f] Make -machine/-enable-kvm options merge into a single list +git bisect good 9de36b1a7cf61aa8be365f13c81668b3e19fbc7f +# bad: [3edb8f92e8b5f18797693d8ed9fad3962e11e25d] target-s390x: Pass S390CPU to s390_cpu_restart() +git bisect bad 3edb8f92e8b5f18797693d8ed9fad3962e11e25d +# good: [aecff6924dab0197b6c8f132e44502b25fd98a38] hw/arm_gic: Make gic_reset a sysbus reset function +git bisect good aecff6924dab0197b6c8f132e44502b25fd98a38 +# good: [b9531b6eed93c9e1769d6f371c4da5d1f955e0d1] block/qcow2: Add missing GCC_FMT_ATTR to function report_unsupported() +git bisect good b9531b6eed93c9e1769d6f371c4da5d1f955e0d1 +# good: [dd86df756e02b684718dd5378725927361b0ad36] Merge remote-tracking branch 'sstabellini/for_1.1_rc3' into staging +git bisect good dd86df756e02b684718dd5378725927361b0ad36 +# good: [8ebdf9dcc6036171a9f8bac3fe8dc459725a3e83] sun4u: Use cpu_sparc_init() to obtain SPARCCPU +git bisect good 8ebdf9dcc6036171a9f8bac3fe8dc459725a3e83 +# good: [8867aef02e1e5817c72b2e09be4ae952eb0c9d9d] build: move ui/ objects to nested Makefile.objs +git bisect good 8867aef02e1e5817c72b2e09be4ae952eb0c9d9d +# bad: [e8de1ea849176812765bf30514f66c5450a1edc6] target-xtensa: add attributes to helper functions +git bisect bad e8de1ea849176812765bf30514f66c5450a1edc6 +# bad: [fa79c914efd35cb60e0bc18512c03690c48b13e2] Merge remote-tracking branch 'bonzini/nested-makefiles-3' into staging +git bisect bad fa79c914efd35cb60e0bc18512c03690c48b13e2 +# good: [c353f261946ddbd814b333ae2440712b486977fd] build: move per-target hw/ objects to nested Makefile.objs +git bisect good c353f261946ddbd814b333ae2440712b486977fd +# bad: [25f27a4f7160d077d6992e811021b4bc3a82abc1] build: compile oslib-obj-y once +git bisect bad 25f27a4f7160d077d6992e811021b4bc3a82abc1 +# bad: [00c705fb92bc6e69e955aeac3614e05ca02feacd] build: libcacard Makefile cleanups +git bisect bad 00c705fb92bc6e69e955aeac3614e05ca02feacd +# good: [49ac9e0a8cfb737d6da9c0b056c062e3dec0ba45] build: move device tree to per-target Makefile.objs +git bisect good 49ac9e0a8cfb737d6da9c0b056c062e3dec0ba45 + +On 12/03/13 09:06, Paolo Bonzini wrote: +> Il 03/12/2013 14:25, Stefano Stabellini ha scritto: +>> CC'ing Paolo and xen-devel. +>> The original thread is here: +>> +>> http://marc.info/?l=xen-devel&m=135718999710640 +>> +>> On Mon, 2 Dec 2013, Don Slutz wrote: +>>>> Public bug reported: +>>>> +>>>> lt LINK libcacard.la +>>>> /usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' can not be used when making a shared object; recompile with -fPIC +>>>> /usr/bin/ld: final link failed: Bad value +>>>> collect2: ld returned 1 exit status +>>>> make[4]: *** [libcacard.la] Error 1 +>>>> make[3]: *** [subdir-libcacard] Error 2 +> Thanks, I'll try to reproduce. Please send the "make V=1" output for a +> full build in the meanwhile. +Here it is for a full build of: + +* 7dc65c0 (HEAD, origin/master, origin/HEAD, master) Open 2.0 +development tree + + -Don Slutz +> Paolo + + + +On 12/03/13 12:15, Paolo Bonzini wrote: +> Il 03/12/2013 14:25, Stefano Stabellini ha scritto: +>> CC'ing Paolo and xen-devel. +>> The original thread is here: +>> +>> http://marc.info/?l=xen-devel&m=135718999710640 +>> +>> On Mon, 2 Dec 2013, Don Slutz wrote: +>>> Public bug reported: +>>> +>>> lt LINK libcacard.la +>>> /usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' can not be used when making a shared object; recompile with -fPIC +>>> /usr/bin/ld: final link failed: Bad value +>>> collect2: ld returned 1 exit status +>>> make[4]: *** [libcacard.la] Error 1 +>>> make[3]: *** [subdir-libcacard] Error 2 +> This is a bug in RHEL5 binutils. Configure with --disable-pie to work +> around it. +Any hints or pointers about the bug in RHEL5 binutils? I can try and +make a patch to auto detect this. + +That still fails for (7dc65c0 (HEAD, origin/master, origin/HEAD, master) +Open 2.0 development tree): + +... +libtool --mode=link --tag=CC cc -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 -Wendif-labels -Wmissing-include-dirs +-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self +-Wold-style-definition -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/don/qemu/dtc/libfdt -pthread +-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include +-I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +-Wl,--warn-common -m64 -g -o vscclient libcacard/vscclient.o +libcacard.la -Wc,-fstack-protector-all -lrt -pthread -L/lib64 +-lgthread-2.0 -lglib-2.0 -lz -L/usr/kerberos/lib64 -lcurl -ldl +-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz -luuid +cc -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 -Wendif-labels +-Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k +-Winit-self -Wold-style-definition -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/don/qemu/dtc/libfdt -pthread +-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include +-I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +-Wl,--warn-common -m64 -g -o .libs/vscclient libcacard/vscclient.o +-Wl,-fstack-protector-all -pthread ./.libs/libcacard.so -L/lib64 +-L/usr/kerberos/lib64 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 +-lnspr4 -lpthread -lrt -lgthread-2.0 -lglib-2.0 -lcurl -ldl +-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz +-luuid -Wl,--rpath -Wl,/usr/local/lib +/usr/bin/ld: -f may not be used without -shared +collect2: ld returned 1 exit status +make: *** [vscclient] Error 1 + +Attached is the full "make V=1" output. + +Here is the configure output: + +dcs-xen-53:~/qemu>rm -rf out/tmp;mkdir out/tmp;pushd +out/tmp;../../configure --disable-pie;make V=1 1>zz1 2>&1;popd +~/qemu/out/tmp ~/qemu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +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/don/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler cc +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +QEMU_CFLAGS -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 -Wendif-labels +-Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k +-Winit-self -Wold-style-definition -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$(SRC_PATH)/dtc/libfdt +LDFLAGS -Wl,--warn-common -m64 -g +make make +install install +python python +smbd /usr/sbin/smbd +host CPU x86_64 +host big endian no +target list alpha-softmmu arm-softmmu cris-softmmu i386-softmmu +lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu +mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu +moxie-softmmu or32-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu +s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu +unicore32-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu +alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user +i386-linux-user m68k-linux-user microblaze-linux-user +microblazeel-linux-user mips-linux-user mips64-linux-user +mips64el-linux-user mipsel-linux-user mipsn32-linux-user +mipsn32el-linux-user or32-linux-user ppc-linux-user ppc64-linux-user +ppc64abi32-linux-user s390x-linux-user sh4-linux-user sh4eb-linux-user +sparc-linux-user sparc32plus-linux-user sparc64-linux-user +unicore32-linux-user x86_64-linux-user +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +-Werror enabled no +pixman system +SDL support yes +GTK support no +curses support yes +curl support yes +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support yes +VNC support yes +VNC TLS support no +VNC SASL support yes +VNC JPEG support yes +VNC PNG support yes +VNC WS support no +xen support yes +brlapi support no +bluez support no +Documentation yes +GUEST_BASE yes +PIE no +vde support no +Linux AIO support no +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support yes +preadv support no +fdatasync yes +madvise yes +posix_madvise yes +sigev_thread_id yes +uuid support yes +libcap-ng support no +vhost-net support yes +vhost-scsi support yes +Trace backend nop +Trace output file trace-<pid> +spice support no (/) +rbd support no +xfsctl support no +nss used yes +libusb no +usb net redir no +GLX support yes +libiscsi support no +build guest agent yes +QGA VSS support no +seccomp support no +coroutine backend ucontext +coroutine pool yes +GlusterFS support no +virtio-blk-data-plane no +gcov gcov +gcov enabled no +TPM support no +libssh2 support no +TPM passthrough no +QOM debugging yes +vhdx yes + +I bisect'd this to: + +dcs-xen-53:~/qemu>git-bisect good +37746c5eacf309fa019ea0fa45f776c36c561457 is the first bad commit +commit 37746c5eacf309fa019ea0fa45f776c36c561457 +Author: Marc-André Lureau <email address hidden> +Date: Mon Feb 25 23:31:12 2013 +0100 + + build-sys: must link with -fstack-protector + + It is needed to give that flag to the linker as well, but latest + libtool 2.4.2 still swallows that argument, so let's pass it with + libtool -Wc argument. + + qemu-1.4.0/stubs/arch-query-cpu-def.c:6: undefined reference to +`__stack_chk_guard' + + Signed-off-by: Marc-André Lureau <email address hidden> + Reviewed-by: Alon Levy <email address hidden> + +:100755 100755 33d3354ea30838694020660f5822f551293d7e9a +ee2e7e8ad9b8a23af96e4e404e3f7658efcbe74b M configure +:100644 100644 edc2552f0886c99608b97f85bd932460fa50da73 +36aba2de1fa9e0f8acde7640818e94a28dd03c80 M rules.mak + +Do you want a bug opened for this? + + -Don Slutz + +> Paolo + + + +On 12/05/13 10:18, Paolo Bonzini wrote: +> Il 04/12/2013 02:32, Don Slutz ha scritto: +>> Any hints or pointers about the bug in RHEL5 binutils? I can try and +>> make a patch to auto detect this. +> Actually it's RHEL5 GCC: +> +> $ cat f.c +> void * +> f(unsigned char *buf, int len) +> { +> return (void*)0L; +> } +> +> +> void * +> g(unsigned char *buf, int len) +> { +> return f(buf, len); +> } +> $ gcc -shared -o f.so f.c -fPIE -fPIC +> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> +> +> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +> +> $ gcc -S -o - f.c -fPIE |grep call +> call f # PC32 relocation +> $ gcc -S -o - f.c -fPIC |grep call +> call f@PLT # PLT32 relocation +> +> On RHEL5: +> $ gcc -S -o - f.c -fPIE -fPIC |grep call +> call f +> +> On RHEL6: +> $ gcc -S -o - f.c -fPIE -fPIC |grep call +> call f@PLT +> +> Paolo +How about this as a patch: + + From 282fba086186ff3b8e2b2b15e647df2b58d082dd Mon Sep 17 00:00:00 2001 +From: Don Slutz <email address hidden> +Date: Thu, 5 Dec 2013 18:50:18 +0000 +Subject: [PATCH] configure: Auto disabling of PIE due to broken toolchain + support (bug #1257099) + +See https://bugs.launchpad.net/bugs/1257099 + +On RHEL5 GCC, you can get 'relocation R_X86_64_PC32' errors from ld. +So disable PIE is this is true. + +Signed-off-by: Don Slutz <email address hidden> +--- + configure | 43 +++++++++++++++++++++++++++++++++++-------- + 1 file changed, 35 insertions(+), 8 deletions(-) + +diff --git a/configure b/configure +index cf8123b..a51a9dd 100755 +--- a/configure ++++ b/configure +@@ -1339,23 +1339,50 @@ if test "$pie" != "no" ; then + # define THREAD + #endif + ++void *f(unsigned char *buf, int len); ++void *g(unsigned char *buf, int len); ++ ++void * ++f(unsigned char *buf, int len) ++{ ++ return (void*)0L; ++} ++ ++ ++void * ++g(unsigned char *buf, int len) ++{ ++ return f(buf, len); ++} ++ ++#ifdef PIE + static THREAD int tls_var; + + int main(void) { return tls_var; } ++#endif + + EOF +- if compile_prog "-fPIE -DPIE" "-pie"; then +- QEMU_CFLAGS="-fPIE -DPIE $QEMU_CFLAGS" +- LDFLAGS="-pie $LDFLAGS" +- pie="yes" +- if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then +- LDFLAGS="-Wl,-z,relro -Wl,-z,now $LDFLAGS" ++ if compile_prog "-shared -fPIE -fPIC" ""; then ++ if compile_prog "-fPIE -DPIE" "-pie"; then ++ QEMU_CFLAGS="-fPIE -DPIE $QEMU_CFLAGS" ++ LDFLAGS="-pie $LDFLAGS" ++ pie="yes" ++ if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then ++ LDFLAGS="-Wl,-z,relro -Wl,-z,now $LDFLAGS" ++ fi ++ else ++ if test "$pie" = "yes"; then ++ error_exit "PIE not available due to missing toolchain support" ++ else ++ echo "Disabling PIE due to missing toolchain support" ++ pie="no" ++ fi + fi + else + if test "$pie" = "yes"; then +- error_exit "PIE not available due to missing toolchain support" ++ error_exit "PIE not available due to broken toolchain support" + else +- echo "Disabling PIE due to missing toolchain support" ++ echo "Disabling PIE due to broken toolchain support" + pie="no" + fi + fi +-- +1.8.2.1 + + + +On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +> $ gcc -shared -o f.so f.c -fPIE -fPIC +> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> +> +> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +> +> $ gcc -S -o - f.c -fPIE |grep call +> call f # PC32 relocation +> $ gcc -S -o - f.c -fPIC |grep call +> call f@PLT # PLT32 relocation + +The easy workaround is to drop -fPIE when we're adding -fPIC. + + +r~ + + +On 12/05/13 16:24, Richard Henderson wrote: +> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +>> $ gcc -shared -o f.so f.c -fPIE -fPIC +>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC +>> /usr/bin/ld: final link failed: Bad value +>> collect2: ld returned 1 exit status +>> +>> +>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +>> +>> $ gcc -S -o - f.c -fPIE |grep call +>> call f # PC32 relocation +>> $ gcc -S -o - f.c -fPIC |grep call +>> call f@PLT # PLT32 relocation +> The easy workaround is to drop -fPIE when we're adding -fPIC. +> +> +> r~ +Here is a possible patch based on this statement: + + From 6e57382c58fa1b9be0fe9db8f35f53a7a7858ccd Mon Sep 17 00:00:00 2001 +From: Don Slutz <email address hidden> +Date: Fri, 6 Dec 2013 03:12:12 +0000 +Subject: [PATCH] configure: Auto disabling of libtool due to broken +toolchain + support (bug #1257099) + +See https://bugs.launchpad.net/bugs/1257099 + +On RHEL5 GCC with libtool and PIE, you get 'relocation R_X86_64_PC32' +errors from ld. +So disable libtool which disables smartcard-nss (aka nss) if this is true. + +Signed-off-by: Don Slutz <email address hidden> +--- + configure | 27 +++++++++++++++++++++++++++ + 1 file changed, 27 insertions(+) + +diff --git a/configure b/configure +index 0666228..5e34095 100755 +--- a/configure ++++ b/configure +@@ -1310,6 +1310,33 @@ if compile_prog "-Werror -fno-gcse" "" ; then + TRANSLATE_OPT_CFLAGS=-fno-gcse + fi + ++# check for broken GCC in RHEL5 with PIE ++if test -n "$libtool" -a "$pie" = "" ; then ++ cat > $TMPC << EOF ++ ++void *f(unsigned char *buf, int len); ++void *g(unsigned char *buf, int len); ++ ++void * ++f(unsigned char *buf, int len) ++{ ++ return (void*)0L; ++} ++ ++void * ++g(unsigned char *buf, int len) ++{ ++ return f(buf, len); ++} ++ ++EOF ++ if ! compile_prog "-shared -fPIE -fPIC" ""; then ++ echo "Disabling libtool due to broken toolchain support" ++ echo "Defaulting to --disable-smartcard-nss" ++ libtool= ++ fi ++fi ++ + if test "$static" = "yes" ; then + if test "$pie" = "yes" ; then + error_exit "static and pie are mutually incompatible" +-- +1.8.2.1 + + -Don Slutz + + +On 12/05/13 10:18, Paolo Bonzini wrote: +> Il 04/12/2013 02:32, Don Slutz ha scritto: +>> Any hints or pointers about the bug in RHEL5 binutils? I can try and +>> make a patch to auto detect this. +> Actually it's RHEL5 GCC: +> +> $ cat f.c +> void * +> f(unsigned char *buf, int len) +> { +> return (void*)0L; +> } +> +> +> void * +> g(unsigned char *buf, int len) +> { +> return f(buf, len); +> } +> $ gcc -shared -o f.so f.c -fPIE -fPIC +> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> +> +> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +> +> $ gcc -S -o - f.c -fPIE |grep call +> call f # PC32 relocation +> $ gcc -S -o - f.c -fPIC |grep call +> call f@PLT # PLT32 relocation +> +> On RHEL5: +> $ gcc -S -o - f.c -fPIE -fPIC |grep call +> call f +> +> On RHEL6: +> $ gcc -S -o - f.c -fPIE -fPIC |grep call +> call f@PLT +> +> Paolo +RHEL5 also "works" if you add -pie: + +dcs-xen-53:~/tmp>gcc -shared -o f.so f.c -fPIE -fPIC +/usr/bin/ld: /tmp/cc6pp1n2.o: relocation R_X86_64_PC32 against `f' can +not be used when making a shared object; recompile with -fPIC +/usr/bin/ld: final link failed: Bad value +collect2: ld returned 1 exit status +dcs-xen-53:~/tmp>gcc -shared -o f.so f.c -fPIE -fPIC -pie +dcs-xen-53:~/tmp>gcc -S -o - f.c -fPIE -pie|grep call + call f + +I have not figured out a way to take advantage of this. + +I just checked and Fedora 17 has the same issue with gcc: +FC17: +dcs-xen-52:~/tmp>gcc -S -o - f.c -fPIE -fPIC |grep call + call f +dcs-xen-52:~/tmp>gcc -shared -o f.so f.c -fPIE -fPIC +/usr/bin/ld: /tmp/ccUlVgMP.o: relocation R_X86_64_PC32 against symbol +`f' can not be used when making a shared object; recompile with -fPIC +/usr/bin/ld: final link failed: Bad value +collect2: error: ld returned 1 exit status + +However QEMU builds just fine. So it is looking like libtool is also +part of the problem. + + -Don Slutz + + +On 12/05/13 22:20, Don Slutz wrote: +> On 12/05/13 16:24, Richard Henderson wrote: +>> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +>>> $ gcc -shared -o f.so f.c -fPIE -fPIC +>>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' +>>> can not be used when making a shared object; recompile with -fPIC +>>> /usr/bin/ld: final link failed: Bad value +>>> collect2: ld returned 1 exit status +>>> +>>> +>>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +>>> +>>> $ gcc -S -o - f.c -fPIE |grep call +>>> call f # PC32 relocation +>>> $ gcc -S -o - f.c -fPIC |grep call +>>> call f@PLT # PLT32 relocation +>> The easy workaround is to drop -fPIE when we're adding -fPIC. +>> +>> +>> r~ +[snip] + +Attached is a much better version. It drops -fPIE and adds -fPIC for +libtool. + + -Don Slutz + + +On 12/09/13 08:22, Paolo Bonzini wrote: +> Il 09/12/2013 13:47, Don Slutz ha scritto: +>> On 12/05/13 22:20, Don Slutz wrote: +>>> On 12/05/13 16:24, Richard Henderson wrote: +>>>> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +>>>>> $ gcc -shared -o f.so f.c -fPIE -fPIC +>>>>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' +>>>>> can not be used when making a shared object; recompile with -fPIC +>>>>> /usr/bin/ld: final link failed: Bad value +>>>>> collect2: ld returned 1 exit status +>>>>> +>>>>> +>>>>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +>>>>> +>>>>> $ gcc -S -o - f.c -fPIE |grep call +>>>>> call f # PC32 relocation +>>>>> $ gcc -S -o - f.c -fPIC |grep call +>>>>> call f@PLT # PLT32 relocation +>>>> The easy workaround is to drop -fPIE when we're adding -fPIC. +>>>> +>>>> +>>>> r~ +>> [snip] +>> +>> Attached is a much better version. It drops -fPIE and adds -fPIC for +>> libtool. +> It's not much better, because using position-independent code for shared +> libraries is really platform-dependent knowledge of the kind that +> libtool is supposed to hide. +> +> For example, on Mac OS X everything is position-independent by default. +> And on some platforms you have -fpic instead of -fPIC. +> +> So I prefer the patch you had that disabled libtool if the platform is +> buggy. +> +> Paolo +Well, the detection code is too simple: + +FC17 system: + + dcs-xen-52:~/tmp/libtool>uname -a + Linux dcs-xen-52 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 + UTC 2013 x86_64 x86_64 x86_64 GNU/Linux + dcs-xen-52:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC -o f.so + /usr/bin/ld: /tmp/ccl4By1r.o: relocation R_X86_64_PC32 against + symbol `f' can not be used when making a shared object; recompile + with -fPIC + /usr/bin/ld: final link failed: Bad value + collect2: error: ld returned 1 exit status + dcs-xen-52:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE + -DPIE f.c + libtool: compile: gcc -g -c -DPIE f.c -fPIC -DPIC -o .libs/f.o + libtool: compile: gcc -g -c -DPIE f.c -fPIE -o f.o >/dev/null 2>&1 + dcs-xen-52:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo + -rpath /usr/local/lib + libtool: link: gcc -shared -fPIC -DPIC .libs/f.o -Wl,-soname + -Wl,libf.so.0 -o .libs/libf.so.0.0.0 + libtool: link: (cd ".libs" && rm -f "libf.so.0" && ln -s + "libf.so.0.0.0" "libf.so.0") + libtool: link: (cd ".libs" && rm -f "libf.so" && ln -s + "libf.so.0.0.0" "libf.so") + libtool: link: ar cru .libs/libf.a f.o + libtool: link: ranlib .libs/libf.a + libtool: link: ( cd ".libs" && rm -f "libf.la" && ln -s "../libf.la" + "libf.la" ) + +CentOS 5.10: + + dcs-xen-53:~/tmp/libtool>uname -a + Linux dcs-xen-53 2.6.18-371.el5xen #1 SMP Tue Oct 1 09:15:30 EDT + 2013 x86_64 x86_64 x86_64 GNU/Linux + dcs-xen-53:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC -o f.so + /usr/bin/ld: /tmp/ccAy1vZK.o: relocation R_X86_64_PC32 against `f' + can not be used when making a shared object; recompile with -fPIC + /usr/bin/ld: final link failed: Bad value + collect2: ld returned 1 exit status + dcs-xen-53:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE + -DPIE f.c + mkdir .libs + gcc -g -c -fPIE -DPIE f.c -fPIC -DPIC -o .libs/f.o + gcc -g -c -fPIE -DPIE f.c -o f.o >/dev/null 2>&1 + dcs-xen-53:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo + -rpath /usr/local/lib + gcc -shared .libs/f.o -Wl,-soname -Wl,libf.so.0 -o + .libs/libf.so.0.0.0 + /usr/bin/ld: .libs/f.o: relocation R_X86_64_PC32 against `f' can not + be used when making a shared object; recompile with -fPIC + /usr/bin/ld: final link failed: Bad value + collect2: ld returned 1 exit status + +I have attached a patch that uses libtool to determine if gcc & libtool +is broken. + -Don + + + +On 12/14/13 15:21, Don Slutz wrote: +> On 12/09/13 08:22, Paolo Bonzini wrote: +>> Il 09/12/2013 13:47, Don Slutz ha scritto: +>>> On 12/05/13 22:20, Don Slutz wrote: +>>>> On 12/05/13 16:24, Richard Henderson wrote: +>>>>> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +>>>>>> $ gcc -shared -o f.so f.c -fPIE -fPIC +>>>>>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' +>>>>>> can not be used when making a shared object; recompile with -fPIC +>>>>>> /usr/bin/ld: final link failed: Bad value +>>>>>> collect2: ld returned 1 exit status +>>>>>> +>>>>>> +>>>>>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +>>>>>> +>>>>>> $ gcc -S -o - f.c -fPIE |grep call +>>>>>> call f # PC32 relocation +>>>>>> $ gcc -S -o - f.c -fPIC |grep call +>>>>>> call f@PLT # PLT32 relocation +>>>>> The easy workaround is to drop -fPIE when we're adding -fPIC. +>>>>> +>>>>> +>>>>> r~ +>>> [snip] +>>> +>>> Attached is a much better version. It drops -fPIE and adds -fPIC for +>>> libtool. +>> It's not much better, because using position-independent code for shared +>> libraries is really platform-dependent knowledge of the kind that +>> libtool is supposed to hide. +>> +>> For example, on Mac OS X everything is position-independent by default. +>> And on some platforms you have -fpic instead of -fPIC. +>> +>> So I prefer the patch you had that disabled libtool if the platform is +>> buggy. +>> +>> Paolo +> Well, the detection code is too simple: +> +> FC17 system: +> +> dcs-xen-52:~/tmp/libtool>uname -a +> Linux dcs-xen-52 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 +> UTC 2013 x86_64 x86_64 x86_64 GNU/Linux +> dcs-xen-52:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC +> -o f.so +> /usr/bin/ld: /tmp/ccl4By1r.o: relocation R_X86_64_PC32 against +> symbol `f' can not be used when making a shared object; recompile +> with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: error: ld returned 1 exit status +> dcs-xen-52:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE +> -DPIE f.c +> libtool: compile: gcc -g -c -DPIE f.c -fPIC -DPIC -o .libs/f.o +> libtool: compile: gcc -g -c -DPIE f.c -fPIE -o f.o >/dev/null 2>&1 +> dcs-xen-52:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la +> f.lo -rpath /usr/local/lib +> libtool: link: gcc -shared -fPIC -DPIC .libs/f.o -Wl,-soname +> -Wl,libf.so.0 -o .libs/libf.so.0.0.0 +> libtool: link: (cd ".libs" && rm -f "libf.so.0" && ln -s +> "libf.so.0.0.0" "libf.so.0") +> libtool: link: (cd ".libs" && rm -f "libf.so" && ln -s +> "libf.so.0.0.0" "libf.so") +> libtool: link: ar cru .libs/libf.a f.o +> libtool: link: ranlib .libs/libf.a +> libtool: link: ( cd ".libs" && rm -f "libf.la" && ln -s +> "../libf.la" "libf.la" ) +> +> CentOS 5.10: +> +> dcs-xen-53:~/tmp/libtool>uname -a +> Linux dcs-xen-53 2.6.18-371.el5xen #1 SMP Tue Oct 1 09:15:30 EDT +> 2013 x86_64 x86_64 x86_64 GNU/Linux +> dcs-xen-53:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC +> -o f.so +> /usr/bin/ld: /tmp/ccAy1vZK.o: relocation R_X86_64_PC32 against `f' +> can not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> dcs-xen-53:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE +> -DPIE f.c +> mkdir .libs +> gcc -g -c -fPIE -DPIE f.c -fPIC -DPIC -o .libs/f.o +> gcc -g -c -fPIE -DPIE f.c -o f.o >/dev/null 2>&1 +> dcs-xen-53:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la +> f.lo -rpath /usr/local/lib +> gcc -shared .libs/f.o -Wl,-soname -Wl,libf.so.0 -o +> .libs/libf.so.0.0.0 +> /usr/bin/ld: .libs/f.o: relocation R_X86_64_PC32 against `f' can +> not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> +> I have attached a patch that uses libtool to determine if gcc & +> libtool is broken. +> -Don +> +Early today it hit me that the new check was a little to early in +configure. Needs to be after PIE check. +Attached is a v2 of the patch. + + -Don Slutz + + From bb68898eb787cbb1748d4aeb31a4184339d38300 Mon Sep 17 00:00:00 2001 +From: Don Slutz <email address hidden> +Date: Sat, 14 Dec 2013 19:43:56 +0000 +Subject: [PATCH] configure: Disable libtool if -fPIE does not work with it + (bug #1257099) + +Adjust TMPO and added TMPB, TMPL, and TMPA. libtool needs the names +to be fixed (TMPB). + +Add new functions do_libtool and libtool_prog. + +Add check for broken gcc and libtool. + +Signed-off-by: Don Slutz <email address hidden> +--- + configure | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- + 1 file changed, 62 insertions(+), 1 deletion(-) + +diff --git a/configure b/configure +index edfea95..852d021 100755 +--- a/configure ++++ b/configure +@@ -12,7 +12,10 @@ else + fi + + TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c" +-TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o" ++TMPB="qemu-conf-${RANDOM}-$$-${RANDOM}" ++TMPO="${TMPDIR1}/${TMPB}.o" ++TMPL="${TMPDIR1}/${TMPB}.lo" ++TMPA="${TMPDIR1}/lib${TMPB}.la" + TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe" + + # NB: do not call "exit" in the trap handler; this is buggy with some +shells; +@@ -86,6 +89,38 @@ compile_prog() { + do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags + } + ++do_libtool() { ++ local mode=$1 ++ shift ++ # Run the compiler, capturing its output to the log. ++ echo $libtool $mode --tag=CC $cc "$@" >> config.log ++ $libtool $mode --tag=CC $cc "$@" >> config.log 2>&1 || return $? ++ # Test passed. If this is an --enable-werror build, rerun ++ # the test with -Werror and bail out if it fails. This ++ # makes warning-generating-errors in configure test code ++ # obvious to developers. ++ if test "$werror" != "yes"; then ++ return 0 ++ fi ++ # Don't bother rerunning the compile if we were already using -Werror ++ case "$*" in ++ *-Werror*) ++ return 0 ++ ;; ++ esac ++ echo $libtool $mode --tag=CC $cc -Werror "$@" >> config.log ++ $libtool $mode --tag=CC $cc -Werror "$@" >> config.log 2>&1 && +return $? ++ error_exit "configure test passed without -Werror but failed with +-Werror." \ ++ "This is probably a bug in the configure script. The failing +command" \ ++ "will be at the bottom of config.log." \ ++ "You can run configure with --disable-werror to bypass this check." ++} ++ ++libtool_prog() { ++ do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO +$TMPC || return $? ++ do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib ++} ++ + # symbolically link $1 to $2. Portable version of "ln -sf". + symlink() { + rm -rf "$2" +@@ -1367,6 +1402,32 @@ EOF + fi + fi + ++# check for broken gcc and libtool in RHEL5 ++if test -n "$libtool" -a "$pie" != "no" ; then ++ cat > $TMPC <<EOF ++ ++void *f(unsigned char *buf, int len); ++void *g(unsigned char *buf, int len); ++ ++void * ++f(unsigned char *buf, int len) ++{ ++ return (void*)0L; ++} ++ ++void * ++g(unsigned char *buf, int len) ++{ ++ return f(buf, len); ++} ++ ++EOF ++ if ! libtool_prog; then ++ echo "Disabling libtool due to broken toolchain support" ++ libtool= ++ fi ++fi ++ + ########################################## + # __sync_fetch_and_and requires at least -march=i486. Many toolchains + # use i686 as default anyway, but for those that don't, an explicit +-- +1.8.2.1 + + + + +Adjust TMPO and added TMPB, TMPL, and TMPA. libtool needs the names +to be fixed (TMPB). + +Add new functions do_libtool and libtool_prog. + +Add check for broken gcc and libtool. + +Signed-off-by: Don Slutz <email address hidden> +--- +Was posted as an attachment. + +https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg02678.html + + configure | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- + 1 file changed, 62 insertions(+), 1 deletion(-) + +diff --git a/configure b/configure +index edfea95..852d021 100755 +--- a/configure ++++ b/configure +@@ -12,7 +12,10 @@ else + fi + + TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c" +-TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o" ++TMPB="qemu-conf-${RANDOM}-$$-${RANDOM}" ++TMPO="${TMPDIR1}/${TMPB}.o" ++TMPL="${TMPDIR1}/${TMPB}.lo" ++TMPA="${TMPDIR1}/lib${TMPB}.la" + TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe" + + # NB: do not call "exit" in the trap handler; this is buggy with some shells; +@@ -86,6 +89,38 @@ compile_prog() { + do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags + } + ++do_libtool() { ++ local mode=$1 ++ shift ++ # Run the compiler, capturing its output to the log. ++ echo $libtool $mode --tag=CC $cc "$@" >> config.log ++ $libtool $mode --tag=CC $cc "$@" >> config.log 2>&1 || return $? ++ # Test passed. If this is an --enable-werror build, rerun ++ # the test with -Werror and bail out if it fails. This ++ # makes warning-generating-errors in configure test code ++ # obvious to developers. ++ if test "$werror" != "yes"; then ++ return 0 ++ fi ++ # Don't bother rerunning the compile if we were already using -Werror ++ case "$*" in ++ *-Werror*) ++ return 0 ++ ;; ++ esac ++ echo $libtool $mode --tag=CC $cc -Werror "$@" >> config.log ++ $libtool $mode --tag=CC $cc -Werror "$@" >> config.log 2>&1 && return $? ++ error_exit "configure test passed without -Werror but failed with -Werror." \ ++ "This is probably a bug in the configure script. The failing command" \ ++ "will be at the bottom of config.log." \ ++ "You can run configure with --disable-werror to bypass this check." ++} ++ ++libtool_prog() { ++ do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO $TMPC || return $? ++ do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib ++} ++ + # symbolically link $1 to $2. Portable version of "ln -sf". + symlink() { + rm -rf "$2" +@@ -1367,6 +1402,32 @@ EOF + fi + fi + ++# check for broken gcc and libtool in RHEL5 ++if test -n "$libtool" -a "$pie" != "no" ; then ++ cat > $TMPC <<EOF ++ ++void *f(unsigned char *buf, int len); ++void *g(unsigned char *buf, int len); ++ ++void * ++f(unsigned char *buf, int len) ++{ ++ return (void*)0L; ++} ++ ++void * ++g(unsigned char *buf, int len) ++{ ++ return f(buf, len); ++} ++ ++EOF ++ if ! libtool_prog; then ++ echo "Disabling libtool due to broken toolchain support" ++ libtool= ++ fi ++fi ++ + ########################################## + # __sync_fetch_and_and requires at least -march=i486. Many toolchains + # use i686 as default anyway, but for those that don't, an explicit +-- +1.8.2.1 + + + +On 01/02/14 21:12, Don Slutz wrote: + +Ping. + +> Adjust TMPO and added TMPB, TMPL, and TMPA. libtool needs the names +> to be fixed (TMPB). +> +> Add new functions do_libtool and libtool_prog. +> +> Add check for broken gcc and libtool. +> +> Signed-off-by: Don Slutz <email address hidden> +> --- +> Was posted as an attachment. +> +> https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg02678.html +> +> configure | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- +> 1 file changed, 62 insertions(+), 1 deletion(-) +> +> diff --git a/configure b/configure +> index edfea95..852d021 100755 +> --- a/configure +> +++ b/configure +> @@ -12,7 +12,10 @@ else +> fi +> +> TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c" +> -TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o" +> +TMPB="qemu-conf-${RANDOM}-$$-${RANDOM}" +> +TMPO="${TMPDIR1}/${TMPB}.o" +> +TMPL="${TMPDIR1}/${TMPB}.lo" +> +TMPA="${TMPDIR1}/lib${TMPB}.la" +> TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe" +> +> # NB: do not call "exit" in the trap handler; this is buggy with some shells; +> @@ -86,6 +89,38 @@ compile_prog() { +> do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags +> } +> +> +do_libtool() { +> + local mode=$1 +> + shift +> + # Run the compiler, capturing its output to the log. +> + echo $libtool $mode --tag=CC $cc "$@" >> config.log +> + $libtool $mode --tag=CC $cc "$@" >> config.log 2>&1 || return $? +> + # Test passed. If this is an --enable-werror build, rerun +> + # the test with -Werror and bail out if it fails. This +> + # makes warning-generating-errors in configure test code +> + # obvious to developers. +> + if test "$werror" != "yes"; then +> + return 0 +> + fi +> + # Don't bother rerunning the compile if we were already using -Werror +> + case "$*" in +> + *-Werror*) +> + return 0 +> + ;; +> + esac +> + echo $libtool $mode --tag=CC $cc -Werror "$@" >> config.log +> + $libtool $mode --tag=CC $cc -Werror "$@" >> config.log 2>&1 && return $? +> + error_exit "configure test passed without -Werror but failed with -Werror." \ +> + "This is probably a bug in the configure script. The failing command" \ +> + "will be at the bottom of config.log." \ +> + "You can run configure with --disable-werror to bypass this check." +> +} +> + +> +libtool_prog() { +> + do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO $TMPC || return $? +> + do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib +> +} +> + +> # symbolically link $1 to $2. Portable version of "ln -sf". +> symlink() { +> rm -rf "$2" +> @@ -1367,6 +1402,32 @@ EOF +> fi +> fi +> +> +# check for broken gcc and libtool in RHEL5 +> +if test -n "$libtool" -a "$pie" != "no" ; then +> + cat > $TMPC <<EOF +> + +> +void *f(unsigned char *buf, int len); +> +void *g(unsigned char *buf, int len); +> + +> +void * +> +f(unsigned char *buf, int len) +> +{ +> + return (void*)0L; +> +} +> + +> +void * +> +g(unsigned char *buf, int len) +> +{ +> + return f(buf, len); +> +} +> + +> +EOF +> + if ! libtool_prog; then +> + echo "Disabling libtool due to broken toolchain support" +> + libtool= +> + fi +> +fi +> + +> ########################################## +> # __sync_fetch_and_and requires at least -march=i486. Many toolchains +> # use i686 as default anyway, but for those that don't, an explicit + + + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=66518bf668f09eaab14c174 +==> Fix released. + diff --git a/results/classifier/zero-shot/108/none/1272 b/results/classifier/zero-shot/108/none/1272 new file mode 100644 index 000000000..2f8ca3af2 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1272 @@ -0,0 +1,65 @@ +other: 0.449 +KVM: 0.443 +device: 0.379 +performance: 0.371 +boot: 0.368 +vnc: 0.340 +files: 0.335 +graphic: 0.320 +permissions: 0.314 +debug: 0.306 +socket: 0.266 +PID: 0.264 +network: 0.260 +semantic: 0.253 + +qemu 7.1: assertion faillure with virtio-scsi in `blk_set_enable_write_cache` +Description of problem: +During the guest boot qemu crashes with the following error: + +> qemu-system-x86_64: ../src/block/block-backend.c:1949: blk_set_enable_write_cache: Assertion `qemu_in_main_thread()' failed. +Steps to reproduce: +1. Start a windows guest +Additional information: +Stacktrace: + +``` +#0 0x00007fd6c3515ce1 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007fd6c34ff537 in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x00007fd6c34ff40f in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#3 0x00007fd6c350e662 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 +#4 0x000056149e2cea03 in blk_set_enable_write_cache (wce=true, blk=0x5614a01c27f0) at ../src/block/block-backend.c:1949 +#5 0x000056149e2d0a67 in blk_set_enable_write_cache (blk=0x5614a01c27f0, wce=<optimized out>) at ../src/block/block-backend.c:1951 +#6 0x000056149dfe9c59 in scsi_disk_apply_mode_select (p=0x7fd6b400c00e "\004", page=<optimized out>, s=<optimized out>) at ../src/hw/scsi/scsi-disk.c:1520 +#7 mode_select_pages (change=true, len=18, p=0x7fd6b400c00e "\004", r=0x7fd6b4001ff0) at ../src/hw/scsi/scsi-disk.c:1570 +#8 scsi_disk_emulate_mode_select (inbuf=<optimized out>, r=0x7fd6b4001ff0) at ../src/hw/scsi/scsi-disk.c:1640 +#9 scsi_disk_emulate_write_data (req=0x7fd6b4001ff0) at ../src/hw/scsi/scsi-disk.c:1934 +#10 0x000056149e18ff16 in virtio_scsi_handle_cmd_req_submit (req=<optimized out>, req=<optimized out>, s=0x5614a12f16b0) at ../src/hw/scsi/virtio-scsi.c:719 +#11 virtio_scsi_handle_cmd_vq (vq=0x7fd6bab92140, s=0x5614a12f16b0) at ../src/hw/scsi/virtio-scsi.c:761 +#12 virtio_scsi_handle_cmd (vq=<optimized out>, vdev=<optimized out>) at ../src/hw/scsi/virtio-scsi.c:775 +#13 virtio_scsi_handle_cmd (vdev=0x5614a12f16b0, vq=0x7fd6bab92140) at ../src/hw/scsi/virtio-scsi.c:765 +#14 0x000056149e1a8aa6 in virtio_queue_notify_vq (vq=0x7fd6bab92140) at ../src/hw/virtio/virtio.c:2365 +#15 0x000056149e3ccea5 in aio_dispatch_handler (ctx=ctx@entry=0x5614a01babe0, node=<optimized out>) at ../src/util/aio-posix.c:369 +#16 0x000056149e3cd868 in aio_dispatch_ready_handlers (ready_list=0x7fd6c09b2680, ctx=0x5614a01babe0) at ../src/util/aio-posix.c:399 +#17 aio_poll (ctx=0x5614a01babe0, blocking=blocking@entry=true) at ../src/util/aio-posix.c:713 +#18 0x000056149e2a7796 in iothread_run (opaque=opaque@entry=0x56149ffde500) at ../src/iothread.c:67 +#19 0x000056149e3d0859 in qemu_thread_start (args=0x7fd6c09b26f0) at ../src/util/qemu-thread-posix.c:504 +#20 0x00007fd6c36b9ea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#21 0x00007fd6c35d9aef in clone () from /lib/x86_64-linux-gnu/libc.so.6 +``` + +The crash was bisected to: + +``` +commit b1c073490553f80594b903ceedfc7c1aef6b1b19 +Author: Hanna Reitz <hreitz@redhat.com> +Date: Tue Mar 29 11:35:45 2022 +0200 + + main-loop: Disable GLOBAL_STATE_CODE() assertions +``` + +I have not been able to reproduce the bug with a linux guest nor with a fresh windows installation. + +The crashes appears with either `writethrough` and `directsync` cache modes but not with `writeback` `none` and `unsafe`. + +Note: if needed I can extract (privately) provide a disk image demonstrating the behavior diff --git a/results/classifier/zero-shot/108/none/1289788 b/results/classifier/zero-shot/108/none/1289788 new file mode 100644 index 000000000..be8320cb9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1289788 @@ -0,0 +1,57 @@ +graphic: 0.408 +performance: 0.358 +device: 0.188 +PID: 0.171 +files: 0.151 +socket: 0.148 +semantic: 0.148 +debug: 0.125 +permissions: 0.124 +boot: 0.116 +network: 0.114 +vnc: 0.105 +other: 0.056 +KVM: 0.049 + +MIDI access (not only adlib) hangs WinNT on QEMU 1.7.x + +Windows NT 4.0 and 2000 (including the latest git release), when enabling adlib (with sb16 already enabled) or the built-in synth of the es1370, hang on QEMU 1.7.x (also with 1.7.50) when they try to play MIDI files (like canyon.mid, etc). I have already tried bisecting but seems that this bug has been introduced sometime in 1.7.0's development time. + +Is this problem still reproducible with the latest version of QEMU? + + +On Mar 6, 2017, at 5:45 AM, <email address hidden> wrote: + +> +> Is this problem still reproducible with the latest version of QEMU? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1289788 +> +> Title: +> MIDI access (not only adlib) hangs WinNT on QEMU 1.7.x +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Windows NT 4.0 and 2000 (including the latest git release), when enabling adlib (with sb16 already enabled) or the built-in synth of the es1370, hang on QEMU 1.7.x (also with 1.7.50) when they try to play MIDI files (like canyon.mid, etc). I have already tried bisecting but seems that this bug has been introduced sometime in 1.7.0's development time. +> Screenshot attached: http://goput.it/ig2l.png +> +> OS Used: Windows 7 x64 Ultimate SP1 +> command-line used: qemu-system-i386w.exe -L pc-bios -m 64 -cpu pentium -drive file=vbent40.img,if=floppy,id=fda -drive file=vhd.vhd,if=ide,media=disk,bus=0,unit=0,id=harddisk0 -drive file=E:,if=ide,media=cdrom,bus=1,unit=0,id=cdrom -net nic,model=pcnet -net user -vga std -device ES1370 -boot menu=on -monitor telnet:127.0.0.1:4444,server,nowait +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1289788/+subscriptions + +A midi file played very will using SB16. It didn't work at all with adlib, and it played poorly in es1370. I used Windows 2000 as the guest. There were no hangs. + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1307 b/results/classifier/zero-shot/108/none/1307 new file mode 100644 index 000000000..2be0afe37 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1307 @@ -0,0 +1,87 @@ +KVM: 0.226 +vnc: 0.193 +other: 0.169 +graphic: 0.168 +debug: 0.164 +PID: 0.163 +device: 0.161 +semantic: 0.160 +performance: 0.159 +permissions: 0.153 +files: 0.151 +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/zero-shot/108/none/1307656 b/results/classifier/zero-shot/108/none/1307656 new file mode 100644 index 000000000..c5a40284a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1307656 @@ -0,0 +1,72 @@ +KVM: 0.580 +other: 0.567 +vnc: 0.549 +permissions: 0.506 +debug: 0.483 +performance: 0.462 +PID: 0.453 +device: 0.435 +graphic: 0.432 +files: 0.426 +boot: 0.421 +network: 0.410 +socket: 0.405 +semantic: 0.398 + +qemu segfault when starting virt-manager + +libvirtd 1.2.3 +virt-manager 1.0.1 +qemu 1.7.92 (2.0.0-rc2) + +1. Initially virt-manager is NOT running + +2. I start a VM manually using "virsh start ...", causing a qemu instance to be run as + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name Zeus_Virtualized -S -machine pc-i440fx-2.0,accel=kvm,usb=off -cpu Penryn -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 6384b4d2-1c58-4595-bce2-b248230e2c9c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Zeus_Virtualized.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=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 virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_USBStick.qcow2,if=none,id=drive-usb-disk0,format=qcow2 -device usb-storage,drive=drive-usb-disk0,id=usb-disk0,removable=off -drive file=/home/pief/isos/openSUSE-13.1-DVD-x86_64.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_HDD1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_HDD2.qcow2,if=none,id=drive-virtio-disk1,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_SSD.qcow2,if=none,id=drive-virtio-disk2,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk2,id=virtio-disk2,bootindex=2 -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 -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=0x3 -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 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 + +3. I start virt-manager (just starting it, nothing special). + +4. The qemu instance segfaults with the attached backtrace. + + + + + +No crash BTW if virt-manager is started first and THEN "virsh start..." is executed. + +Judging by the backtrace this is the bug fixed by commit 92b3eeadd9bc, which is in current git master and will be in the imminent 2.0.0-rc3. + + +Fix is already queued for qemu 2.0 GA + +commit 92b3eeadd9bc72f1f4e5ba1f62a289dc0190e88f +Author: Cole Robinson <email address hidden> +Date: Thu Apr 10 14:47:38 2014 -0400 + + qom: Fix crash with qom-list and link properties + + +On 04/14/14 20:47, Pieter Hollants wrote: +> Public bug reported: +> +> libvirtd 1.2.3 +> virt-manager 1.0.1 +> qemu 1.7.92 (2.0.0-rc2) + +I think this should be fixed by Cole's patch, in rc3: + +commit 92b3eeadd9bc72f1f4e5ba1f62a289dc0190e88f +Author: Cole Robinson <email address hidden> +Date: Thu Apr 10 14:47:38 2014 -0400 + + qom: Fix crash with qom-list and link properties + +http://thread.gmane.org/gmane.comp.emulators.qemu/266588 + +Laszlo + + + +Yep, confirm it's fixed in rc3. + diff --git a/results/classifier/zero-shot/108/none/1308 b/results/classifier/zero-shot/108/none/1308 new file mode 100644 index 000000000..d9b7dd3c2 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1308 @@ -0,0 +1,16 @@ +device: 0.513 +graphic: 0.427 +performance: 0.401 +PID: 0.292 +network: 0.288 +vnc: 0.234 +semantic: 0.203 +boot: 0.198 +debug: 0.164 +files: 0.099 +socket: 0.071 +other: 0.031 +permissions: 0.020 +KVM: 0.001 + +Qemu headless build process is stopped, complaining about a missing pixman.h diff --git a/results/classifier/zero-shot/108/none/1318746 b/results/classifier/zero-shot/108/none/1318746 new file mode 100644 index 000000000..ca63addf2 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1318746 @@ -0,0 +1,49 @@ +device: 0.493 +performance: 0.339 +socket: 0.305 +graphic: 0.237 +semantic: 0.230 +other: 0.218 +boot: 0.216 +vnc: 0.202 +PID: 0.198 +network: 0.171 +files: 0.152 +KVM: 0.134 +debug: 0.107 +permissions: 0.082 + +qemu Windows 7 BSOD when using hv-time + +When I use hv-time sub option and run CPU-Z or 3DMark (Physics Test) the Windiws 7 guest stops with BSOD (SYSTEM_SERVICE_EXCEPTION). It can be easily reproduced by running CPU-Z. It will fail every second or third time you execute CPU-Z and fail during "PCI detection". If I disable hv-time I can run CPU-Z and 3DMark (Physics Test) without any problems. QEMU was called with the following options: + +/usr/bin/taskset -c 4,5,6,7 /usr/bin/qemu-system-x86_64 \ + -machine q35,accel=kvm,kernel_irqchip=on \ + -enable-kvm \ + -serial none \ + -parallel none \ + -monitor none \ + -vga std \ + -boot order=dc \ + -cpu host,hv-time \ + -smp cores=4,threads=1,sockets=1 \ + -m 8192 \ + -k de \ + -rtc base=localtime \ + -drive file=/srv/kvm/maggie-drive0.img,id=drive0,if=none,cache=none,aio=threads \ + -mon chardev=monitor0 \ + -chardev socket,id=monitor0,path=/tmp/maggie.monitor,nowait,server \ + -netdev tap,id=net0,vhost=on,helper=/usr/lib/qemu/qemu-bridge-helper \ + -device virtio-net-pci,netdev=net0,mac=00:00:00:02:01:01 \ + -device virtio-blk-pci,drive=drive0,ioeventfd=on \ + -device ioh3420,bus=pcie.0,id=pcie0,port=1,chassis=1,multifunction=on + +I've removed the VFIO PCI passthrough line of my GPU to make reproduction easier. In any case it happens in both scenarios so VGA passthrough is not the root cause. It happens with linux-3.15-rc5 and linux-3.14.3 with patch from commit mentioned at https://bugzilla.kernel.org/show_bug.cgi?id=73721#c3 + +Forgot to mention. Used qemu version was 2.0.0. + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1319493 b/results/classifier/zero-shot/108/none/1319493 new file mode 100644 index 000000000..a633c19f6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1319493 @@ -0,0 +1,63 @@ +device: 0.599 +graphic: 0.529 +semantic: 0.483 +socket: 0.447 +files: 0.412 +PID: 0.411 +network: 0.376 +performance: 0.358 +permissions: 0.302 +vnc: 0.283 +boot: 0.222 +debug: 0.215 +KVM: 0.196 +other: 0.181 + +strip: '/usr/local/bin/fsdev/virtfs-proxy-helper': No such file make: *** [install] Error 1 + +Folder "fsdev" will not be created in "/usr/local/bin". +Qemu compiled from actual git. + + + +####################################################################### +... +Installing with make install... +========================= Installation results =========================== +install -d -m 0755 "/usr/local/share/doc/qemu" +install -c -m 0644 qemu-doc.html qemu-tech.html "/usr/local/share/doc/qemu" +install -c -m 0644 qmp-commands.txt "/usr/local/share/doc/qemu" +install -d -m 0755 "/usr/local/share/man/man1" +install -c -m 0644 qemu.1 "/usr/local/share/man/man1" +install -c -m 0644 qemu-img.1 "/usr/local/share/man/man1" +install -d -m 0755 "/usr/local/share/man/man8" +install -c -m 0644 qemu-nbd.8 "/usr/local/share/man/man8" +install -d -m 0755 "/usr/local/share/man/man1" +install -c -m 0644 fsdev/virtfs-proxy-helper.1 "/usr/local/share/man/man1" +install -d -m 0755 "/usr/local/share/qemu" +install -d -m 0755 "/usr/local/etc/qemu" +install -c -m 0644 /tmp/qemu/sysconfigs/target/target-x86_64.conf "/usr/local/etc/qemu" +install -d -m 0755 "/usr/local/var"/run +install -d -m 0755 "/usr/local/bin" +libtool --quiet --mode=install install -c -m 0755 qemu-ga qemu-nbd qemu-img qemu-io fsdev/virtfs-proxy-helper "/usr/local/bin" +strip "/usr/local/bin/qemu-ga" "/usr/local/bin/qemu-nbd" "/usr/local/bin/qemu-img" "/usr/local/bin/qemu-io" "/usr/local/bin/fsdev/virtfs-proxy-helper" +strip: '/usr/local/bin/fsdev/virtfs-proxy-helper': No such file +make: *** [install] Error 1 + +2014.06.03 Problem remains current + +I'm having the same problem. + +It looks like this was introduced by the following commit: + +commit 2115182f0c3125935b18ee788ef5b36c3c68d911 +Author: Michael Tokarev <email address hidden> +Date: Thu May 8 14:56:58 2014 +0400 + + Makefile: strip tools and modules too + +In my opinion, addprefix would be an even more readable approach, but regardless I think using notdir on the base variable(s) is necessary. + +This was fixed by commit 0d6594261 back in 2014. + + diff --git a/results/classifier/zero-shot/108/none/1333688 b/results/classifier/zero-shot/108/none/1333688 new file mode 100644 index 000000000..eb67134da --- /dev/null +++ b/results/classifier/zero-shot/108/none/1333688 @@ -0,0 +1,75 @@ +device: 0.497 +network: 0.484 +PID: 0.461 +vnc: 0.365 +socket: 0.278 +graphic: 0.222 +debug: 0.149 +boot: 0.147 +performance: 0.136 +semantic: 0.132 +KVM: 0.131 +other: 0.125 +files: 0.124 +permissions: 0.123 + +vhost-user: VHOST_USER_SET_MEM_TABLE doesn't contain all regions + + + +vhost-user implementation doesn't provide information about all memory regions, +and in some cases client is not able to map buffer memory as he is missing +memory region information for specific address. + +Same thing is implemented properly for vhost-net. Below gdb outputs are +showing memory regions information provided to the vhost-net and vhost-user. + + + +==== memory regions information provided to vhost-net ==== + +(gdb) p/x hdev->mem->regions[0] +$21 = { + guest_phys_addr = 0x100000000, + memory_size = 0xc0000000, + userspace_addr = 0x2aab6ac00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[1] +$22 = { + guest_phys_addr = 0xfffc0000, + memory_size = 0x40000, + userspace_addr = 0x7ffff4a00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[2] +$23 = { + guest_phys_addr = 0x0, + memory_size = 0xa0000, + userspace_addr = 0x2aaaaac00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[3] +$24 = { + guest_phys_addr = 0xc0000, + memory_size = 0xbff40000, + userspace_addr = 0x2aaaaacc0000, + flags_padding = 0x0 +} +(gdb) + + +==== memory regions information provided to vhost-user ==== + +(gdb) p/x msg.memory.nregions +$28 = 0x1 +(gdb) p/x msg.memory.regions[0] +$29 = { + guest_phys_addr = 0x0, + memory_size = 0x180000000, + userspace_addr = 0x2aaaaac00000 +} +(gdb) + +Problem fixed in qemu commit 3fd74b84. + diff --git a/results/classifier/zero-shot/108/none/1347 b/results/classifier/zero-shot/108/none/1347 new file mode 100644 index 000000000..bdde792bd --- /dev/null +++ b/results/classifier/zero-shot/108/none/1347 @@ -0,0 +1,38 @@ +other: 0.569 +KVM: 0.505 +performance: 0.433 +graphic: 0.427 +debug: 0.378 +vnc: 0.371 +device: 0.354 +permissions: 0.335 +semantic: 0.331 +boot: 0.329 +PID: 0.282 +network: 0.281 +socket: 0.280 +files: 0.275 + +qemu-system-arm segfaults: arm_v7m_tcg_ops.restore_state_to_opc is NULL +Description of problem: +gdb backtrace: +``` +#0 0x0000000000000000 in ?? () +#1 0x0000555555eda714 in cpu_restore_state_from_tb (cpu=0x5555570020e0, tb=0x7fffb8f6ce80, host_pc=140735277023274) at ../accel/tcg/translate-all.c:311 +#2 0x0000555555eda785 in cpu_restore_state (cpu=0x5555570020e0, host_pc=140735277023274) at ../accel/tcg/translate-all.c:335 +#3 0x0000555555d01323 in arm_cpu_do_transaction_failed (cs=0x5555570020e0, physaddr=1073885184, addr=1073885184, size=4, access_type=MMU_DATA_LOAD, mmu_idx=1, attrs=..., response=1, retaddr=140735277023274) at ../target/arm/tlb_helper.c:199 +#4 0x0000555555ee4118 in cpu_transaction_failed (cpu=0x5555570020e0, physaddr=1073885184, addr=1073885184, size=4, access_type=MMU_DATA_LOAD, mmu_idx=1, attrs=..., response=1, retaddr=140735277023274) at ../accel/tcg/cputlb.c:1344 +#5 0x0000555555ee42aa in io_readx (env=0x555557003f50, full=0x5555580f26c0, mmu_idx=1, addr=1073885184, retaddr=140735277023274, access_type=MMU_DATA_LOAD, op=MO_32) at ../accel/tcg/cputlb.c:1380 +#6 0x0000555555ee59f2 in load_helper (env=0x555557003f50, addr=1073885184, oi=33, retaddr=140735277023274, op=MO_32, code_read=false, full_load=0x555555ee5dbf <full_le_ldul_mmu>) at ../accel/tcg/cputlb.c:1970 +#7 0x0000555555ee5e12 in full_le_ldul_mmu (env=0x555557003f50, addr=1073885184, oi=33, retaddr=140735277023274) at ../accel/tcg/cputlb.c:2070 +#8 0x0000555555ee5e44 in helper_le_ldul_mmu (env=0x555557003f50, addr=1073885184, oi=33, retaddr=140735277023274) at ../accel/tcg/cputlb.c:2077 +#9 0x00007fff7c31c0be in code_gen_buffer () +#10 0x0000555555ed15b8 in cpu_tb_exec (cpu=0x5555570020e0, itb=0x7fffb8f6ce80, tb_exit=0x7fff7a3fc068) at ../accel/tcg/cpu-exec.c:438 +#11 0x0000555555ed2185 in cpu_loop_exec_tb (cpu=0x5555570020e0, tb=0x7fffb8f6ce80, pc=2824872, last_tb=0x7fff7a3fc080, tb_exit=0x7fff7a3fc068) at ../accel/tcg/cpu-exec.c:868 +#12 0x0000555555ed2545 in cpu_exec (cpu=0x5555570020e0) at ../accel/tcg/cpu-exec.c:1032 +#13 0x0000555555ef3329 in tcg_cpus_exec (cpu=0x5555570020e0) at ../accel/tcg/tcg-accel-ops.c:69 +#14 0x0000555555ef39ca in mttcg_cpu_thread_fn (arg=0x5555570020e0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#15 0x00005555560b1e87 in qemu_thread_start (args=0x5555571358e0) at ../util/qemu-thread-posix.c:505 +#16 0x00007ffff7fb6cbe in start (p=0x7fff7a3fc1e0) at src/thread/pthread_create.c:195 +#17 0x00007ffff7fc3e7b in __clone () at src/thread/x86_64/clone.s:22 +``` diff --git a/results/classifier/zero-shot/108/none/1349722 b/results/classifier/zero-shot/108/none/1349722 new file mode 100644 index 000000000..2668557f6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1349722 @@ -0,0 +1,62 @@ +semantic: 0.552 +graphic: 0.481 +device: 0.463 +performance: 0.443 +other: 0.315 +socket: 0.299 +PID: 0.269 +network: 0.261 +vnc: 0.229 +boot: 0.185 +files: 0.170 +debug: 0.129 +permissions: 0.105 +KVM: 0.062 + +qemu-io: Exit code is always zero + +The qemu-io always returns zero on exit independently on errors occurred during the command execution. + +Example, + +$ qemu-io -c 'write 128 234' /tmp/run1/test-1/test.img + +offset 128 is not sector aligned + +$ echo $? +0 + + +qemu.git HEAD: 41a1a9c42c4e + +On Tue, Jul 29, 2014 at 08:07:44AM -0000, Maria Kustova wrote: +> The qemu-io always returns zero on exit independently on errors occurred +> during the command execution. +> +> Example, +> +> $ qemu-io -c 'write 128 234' /tmp/run1/test-1/test.img +> +> offset 128 is not sector aligned +> +> $ echo $? +> 0 +> +> +> qemu.git HEAD: 41a1a9c42c4e + +For single commands it makes sense to return the command success as the +exit code. + +When qemu-io is used interactively or with multiple -c options we need a +error handling policy. + +For this reason it is not totally trivial to implement. + +Stefan + + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Should be fixed as of 6b3aa8485ca8e. + diff --git a/results/classifier/zero-shot/108/none/1350 b/results/classifier/zero-shot/108/none/1350 new file mode 100644 index 000000000..6a5cd38de --- /dev/null +++ b/results/classifier/zero-shot/108/none/1350 @@ -0,0 +1,104 @@ +other: 0.448 +graphic: 0.414 +performance: 0.406 +permissions: 0.381 +debug: 0.379 +PID: 0.363 +device: 0.363 +semantic: 0.355 +files: 0.341 +KVM: 0.335 +boot: 0.317 +socket: 0.312 +vnc: 0.295 +network: 0.260 + +Regression in 7.2.0rc3: No snow by efi firmware in advent calendar 2020, door 15 anymore +Description of problem: +Advent calendar 2020, door 15 is expected to produce snow on the terminal while executing the provided efi firmware: + +> snow in micropython on slimbootloader by eldon +> ------------------------------------------- +> +> Today's advent is a custom efi firmware build of a new bootloader from intel called +> slimbootloader[1], a recent project by intel which has adapted micropython[2] as a +> utility for configuration and board testing. This build, however, will show snowfall on +> the console for a while. Eventually an exception drops the firmware into the micropython +> repl. +> +> [1] https://slimbootloader.github.io/supported-hardware/qemu.html +> [2] http://docs.micropython.org/en/latest/index.html + + +Snow does not fall anymore as it did with 7.1.0, it seems like execution is stopped/not started +Steps to reproduce: +- Build & Install from git source + ``` + /home/helge/qemu-project/qemu/configure --prefix=/home/helge/qemu-project/install \ + --target-list=x86_64-softmmu --disable-linux-user + make -j2 + make install + ``` + - Execute + ``` + PATH="/home/helge/qemu-project/install/bin" qemu-system-x86_64 \ + -m 256M -machine q35 -serial mon:stdio -vga none \ + -drive if=pflash,format=raw,file=snow.bin -boot a + ``` +Additional information: +Performing git bisect starting with tag v7.1.0 as good and tag v7.2.0-rc3 as bad reveals 92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 as culprit: + ``` +$ git bisect start c4ffd91aba1c3d878e99a3e7ba8aad4826728ece 621da7789083b80d6f1ff1c0fb499334007b4f51 +binäre Suche: danach noch 965 Commits zum Testen übrig (ungefähr 10 Schritte) +[2ba341b3694cf3cff7b8a1df4cc765900d5c4f60] Merge tag 'kraxel-20221013-pull-request' of https://gitlab.com/kraxel/qemu into staging +$ git bisect good +binäre Suche: danach noch 482 Commits zum Testen übrig (ungefähr 9 Schritte) +[05c049f12b88370de7289bf39b14088c7d656caa] hw/isa/piix3: Remove extra ';' outside of functions +$ git bisect bad +binäre Suche: danach noch 228 Commits zum Testen übrig (ungefähr 8 Schritte) +[08a5d04606292b3cf6f5756bf2a095654a290626] Merge tag 'pull-tcg-20221026' of https://gitlab.com/rth7680/qemu into staging +$ git bisect bad +binäre Suche: danach noch 126 Commits zum Testen übrig (ungefähr 7 Schritte) +[168122419ed1c4087748e21131a523c6d9b632e1] target/arm: Change gen_goto_tb to work on displacements +$ git bisect bad +binäre Suche: danach noch 69 Commits zum Testen übrig (ungefähr 6 Schritte) +[2c65091fd9d387b8dca8115dbdd9c3c61f658a9e] Merge tag 'pull-ppc-20221017' of https://gitlab.com/danielhb/qemu into staging +$ git bisect good +binäre Suche: danach noch 34 Commits zum Testen übrig (ungefähr 5 Schritte) +[92ec056a6b2fc5d5a5593121c5d9475d2a2461d6] target/i386: reimplement 0x0f 0x60-0x6f, add AVX +$ git bisect bad +binäre Suche: danach noch 17 Commits zum Testen übrig (ungefähr 4 Schritte) +[8629e77be5f8106b3497cc197fbd57a12ae6333f] target/i386: Use probe_access_full for final stage2 translation +$ git bisect good +binäre Suche: danach noch 8 Commits zum Testen übrig (ungefähr 3 Schritte) +[20581aadec5e5a9d6836e4612b6f44a7cbda7d16] target/i386: validate VEX prefixes via the instructions' exception classes +$ git bisect good +binäre Suche: danach noch 4 Commits zum Testen übrig (ungefähr 2 Schritte) +[f05f9789f57d5394fc118fe31aa2a9f563311140] target/i386: extend helpers to support VEX.V 3- and 4- operand encodings +$ git bisect good +binäre Suche: danach noch 2 Commits zum Testen übrig (ungefähr 1 Schritt) +[620f75566a5d81d7b82b3788b83d0b95c7d21dcd] target/i386: provide 3-operand versions of unary scalar helpers +$ git bisect good +binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 1 Schritt) +[b98f886c8f8661773047197d132efec97810b37a] target/i386: Introduce 256-bit vector helpers +$ git bisect good +92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 is the first bad commit +commit 92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Tue Sep 20 05:42:45 2022 -0400 + + target/i386: reimplement 0x0f 0x60-0x6f, add AVX + + These are both MMX and SSE/AVX instructions, except for vmovdqu. In both + cases the inputs and output is in s->ptr{0,1,2}, so the only difference + between MMX, SSE, and AVX is which helper to call. + + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/decode-new.c.inc | 42 ++++++++ + target/i386/tcg/emit.c.inc | 202 +++++++++++++++++++++++++++++++++++++++ + target/i386/tcg/translate.c | 19 +++- + 3 files changed, 262 insertions(+), 1 deletion(-) + + ``` diff --git a/results/classifier/zero-shot/108/none/1352130 b/results/classifier/zero-shot/108/none/1352130 new file mode 100644 index 000000000..c7229c9f0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1352130 @@ -0,0 +1,48 @@ +graphic: 0.474 +device: 0.333 +network: 0.275 +semantic: 0.264 +socket: 0.222 +vnc: 0.207 +files: 0.198 +performance: 0.191 +permissions: 0.183 +debug: 0.146 +boot: 0.139 +other: 0.114 +PID: 0.106 +KVM: 0.058 + +Feature Request: Add OpenGL/3D acceleration support + +Hello, +I would like to request that support for OpenGL and 3D acceleration be added to QEMU. I am sure it has been discussed before, but at the dawn of a new century there are a number of possible solutions and I haven't seen anything implemented into upstream. + +Options - + +1. VMGL +http://www.cs.toronto.edu/~andreslc/xen-gl/ + +2. Qemu-patch +http://web.archive.org/web/20110721175015/http://qemu-forum.ipi.fi/viewtopic.php?t=2984 + +3. Wine +http://www.winehq.com + +3.a. WineD3D links: (Direct3D-on-OpenGL wrapper) +http://www.virtualbox.org/ticket/3639 +http://www.nongnu.org/wined3d/ + +4. DirectX OpenGL Wrapper +http://sourceforge.net/projects/dxglwrap + +5. Transgaming SwiftShader +This technology allows software rendering of many DirectX effects. + +6. VMware chose Gallium3D: (12.12.2009) +http://vmware-svga.svn.sourceforge.net/viewvc/vmware-svga/trunk/doc/gpu-wiov.pdf?revision=1 + +Thank you. + +This should now be possible with virgl (see https://www.kraxel.org/blog/tag/virgl/ for example for some more details) ==> Closing this ticket. + diff --git a/results/classifier/zero-shot/108/none/1355738 b/results/classifier/zero-shot/108/none/1355738 new file mode 100644 index 000000000..db5acacc3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1355738 @@ -0,0 +1,60 @@ +performance: 0.525 +semantic: 0.504 +graphic: 0.446 +device: 0.389 +files: 0.357 +PID: 0.344 +network: 0.267 +vnc: 0.248 +KVM: 0.247 +socket: 0.234 +permissions: 0.218 +debug: 0.189 +boot: 0.184 +other: 0.119 + +qemu-img: Killed by SIGTRAP on check of the fuzzed image + +'qemu-img check -r all' was killed by SIGTRAP. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.qed in the same directory + 3. Execute + +qemu-img check -f qcow2 -r all copy.img + +Result: qemu-img was killed by SIGTRAP with the reason: + +(process:2210): GLib-ERROR **: gmem.c:140: failed to allocate 18446744069633940288 bytes + +The qemu-img execution log can be found in the attached archive. + +qemu.git HEAD 2d591ce2aeebf + + + +Hi, + +This issue has at least been partially fixed in master (5f77ef69a195098baddfdc6d189f1b4a94587378): + +$ ./qemu-img check -f qcow2 -r all copy.img +# ... +The following inconsistencies were found and repaired: + + 0 leaked clusters + 1 corruptions + +Double checking the fixed image now... + +469 errors were found on the image. +Data may be corrupted, or further writes to the image may corrupt it. + +4766 internal errors have occurred during the check. +2459/4434 = 55.46% allocated, 99.31% fragmented, 10.41% compressed clusters +Image end offset: 2048 + +As with bug 1355697, I'm still working on the repair function. But this image is broken in a way that there's no real way to fix it. The best we could do is ask the user to use qemu-img convert and then hope for the best. I'll just mark this as fixed. + +Max + diff --git a/results/classifier/zero-shot/108/none/1356916 b/results/classifier/zero-shot/108/none/1356916 new file mode 100644 index 000000000..715af406c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1356916 @@ -0,0 +1,25 @@ +device: 0.353 +performance: 0.342 +semantic: 0.153 +graphic: 0.142 +network: 0.090 +socket: 0.079 +PID: 0.059 +boot: 0.040 +other: 0.035 +vnc: 0.033 +debug: 0.019 +KVM: 0.011 +files: 0.010 +permissions: 0.004 + +Too small argv limit + +Current kernels don't have a fixed argv/environ limit any more, but the user-space emulation of qemu is still using a fixed limit. This can cause execve to fail when it wouldn't on a real system. For example, the follwing command should not fail in the emulated environment: + +$ /bin/true $(yes | head -n 100000) +-bash: /bin/true: Argument list too long + +This was fixed in QEMU 2.5. + + diff --git a/results/classifier/zero-shot/108/none/1357206 b/results/classifier/zero-shot/108/none/1357206 new file mode 100644 index 000000000..ce82f121c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1357206 @@ -0,0 +1,83 @@ +performance: 0.323 +device: 0.250 +graphic: 0.250 +semantic: 0.202 +debug: 0.183 +socket: 0.177 +PID: 0.166 +permissions: 0.137 +vnc: 0.131 +network: 0.124 +boot: 0.098 +other: 0.093 +KVM: 0.071 +files: 0.031 + +QEMU user mode still crashes in multi-thread code. + +I compiled the qemu 2.0 release source and find out qemu crashing when emulating multi-thread code in user mode. + +I did a little search and found LP:668799 but it is far from now and it is probably not the problem here. + +I used program below as the test program: + +#include <stdio.h> +#include <stdlib.h> +#include <pthread.h> + +void *print_message_function( void *ptr ); + +main() +{ + pthread_t thread1, thread2; + const char *message1 = "Thread 1"; + const char *message2 = "Thread 2"; + int iret1, iret2; + + /* Create independent threads each of which will execute function */ + + iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1); + if(iret1) + { + fprintf(stderr,"Error - pthread_create() return code: %d\n",iret1); + exit(EXIT_FAILURE); + } + + iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2); + if(iret2) + { + fprintf(stderr,"Error - pthread_create() return code: %d\n",iret2); + exit(EXIT_FAILURE); + } + + printf("pthread_create() for thread 1 returns: %d\n",iret1); + printf("pthread_create() for thread 2 returns: %d\n",iret2); + + /* Wait till threads are complete before main continues. Unless we */ + /* wait we run the risk of executing an exit which will terminate */ + /* the process and all threads before the threads have completed. */ + + pthread_join( thread1, NULL); + pthread_join( thread2, NULL); + + exit(EXIT_SUCCESS); +} + +void *print_message_function( void *ptr ) +{ + char *message; + message = (char *) ptr; + printf("%s \n", message); +} + +Compiled to i386 and aarch64 object, +and both qemu-i386 and qemu-aarch64 had segmentation faults. + +I think this if bug lp:1098729 which is still open. + + + + +This test case now works for me, so I think we have resolved the bug that was showing up here. + + diff --git a/results/classifier/zero-shot/108/none/1357440 b/results/classifier/zero-shot/108/none/1357440 new file mode 100644 index 000000000..8f83f1211 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1357440 @@ -0,0 +1,52 @@ +device: 0.595 +PID: 0.565 +files: 0.563 +semantic: 0.495 +network: 0.490 +graphic: 0.452 +performance: 0.446 +socket: 0.444 +vnc: 0.413 +permissions: 0.381 +boot: 0.323 +KVM: 0.256 +debug: 0.186 +other: 0.134 + +qemu-img: Assert for 'amend' command and the fuzzed image + +'qemu-img amend' failed with the assert on the fuzzed image. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.vdi in the same directory + 3. Execute + qemu-img amend -o compat=0.10 -f qcow2 copy.img + +Result: qemu-img was killed by SIGIOT with the reason: + +qemu-img: block/qcow2-cluster.c:1598: expand_zero_clusters_in_l1: Assertion `(cluster_index >= 0) && (cluster_index < *nb_clusters)' failed. + +qemu.git HEAD 2d591ce2aeebf + + + +Hi, + +This issue should be fixed by my "[PATCH v3 0/7] block/qcow2: Improve zero cluster expansion" series. + +However, there are similar issues in qemu, so we'll probably need a function to quickly mark an image corrupt instead of throwing these assertions. + +Max + +Hi, + +This issue has been fixed in master (af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5, 2.2.0-rc2): + +$ ./qemu-img amend -o compat=0.10 -f qcow2 copy.img +qemu-img: Error while amending options: File too large + +Thanks for your report, + +Max + diff --git a/results/classifier/zero-shot/108/none/1376533 b/results/classifier/zero-shot/108/none/1376533 new file mode 100644 index 000000000..a916fc4b4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1376533 @@ -0,0 +1,25 @@ +device: 0.527 +graphic: 0.522 +semantic: 0.412 +vnc: 0.376 +files: 0.367 +network: 0.358 +socket: 0.271 +permissions: 0.269 +KVM: 0.177 +performance: 0.176 +boot: 0.162 +PID: 0.118 +other: 0.103 +debug: 0.084 + +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/zero-shot/108/none/1376938 b/results/classifier/zero-shot/108/none/1376938 new file mode 100644 index 000000000..badb5b0f7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1376938 @@ -0,0 +1,40 @@ +graphic: 0.496 +device: 0.409 +performance: 0.386 +files: 0.242 +KVM: 0.202 +semantic: 0.165 +boot: 0.147 +PID: 0.131 +other: 0.124 +network: 0.100 +debug: 0.090 +socket: 0.080 +vnc: 0.073 +permissions: 0.067 + +detect-zeroes=unmap fails to discard in some cases + +Under certain circumstances, QEMU 2.1.2 fails to discard the underlaying block. The command to start QEMU is: + +qemu-system-x86_64 -machine pc,accel=kvm -m 2G -smp 2 -vga std -usb -usbdevice tablet -drive if=none,id=ff,aio=native,discard=unmap,detect-zeroes=unmap,file=/tmp/test.qcow2 -device virtio-scsi-pci -device scsi-disk,drive=ff -cdrom /media/iso/archlinux-2014.06.01-dual.iso -vnc :1 + +Steps to reproduce: + + 0. qemu-img create -f qcow2 /tmp/test.qcow2 4G + 1. Boot in the guest (Arch Linux x86_64 with Linux 3.14.4) + 2. cat /dev/zero > /dev/sda. Observe a file of 4109M (size measured with `du -m` + 3. cat /dev/zero > /dev/sda + 4. blkdiscard /dev/sda + 5. Observe that test.qcow2 grows larger than 1M (13M in my testing). + +The results are more severe when you write other kind of data in step 2, for instance `base64 /dev/zero > /dev/sda` and then continuing with step 3 and 4 will result in a file of 3642M, after blkdiscard. + +It makes not much of a difference if I create an ext4 filesystem on top of it and use fstrim (or rm). + +Note that `cat /dev/zero` followed by `blkdiscard` has no issues. + +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/zero-shot/108/none/1381639 b/results/classifier/zero-shot/108/none/1381639 new file mode 100644 index 000000000..270049eb5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1381639 @@ -0,0 +1,34 @@ +socket: 0.597 +device: 0.549 +graphic: 0.357 +vnc: 0.332 +boot: 0.304 +network: 0.277 +PID: 0.196 +semantic: 0.186 +performance: 0.183 +other: 0.146 +files: 0.136 +debug: 0.129 +permissions: 0.037 +KVM: 0.027 + +sys_eeprom.c:353: buffer too small + +[qemu-2.1.2/roms/u-boot/board/matrix_vision/mvblx/sys_eeprom.c:353]: (error) Buffer is accessed out of bounds. + + char ethaddr[9]; + + sprintf(ethaddr, "%02X:%02X:%02X:%02X:%02X:%02X", + e.mac[0], + e.mac[1], + e.mac[2], + e.mac[3], + e.mac[4], + e.mac[5]); + +18 into 9 won't go. Suggest increase size of ethaddr. + +roms/u-boot is not under control of the QEMU project - you should report such bugs to the u-boot project instead. Anyway, looks like the problem has been fixed there: +http://git.denx.de/?p=u-boot.git;a=commitdiff;h=cc87d18a6ec74180784a6b + diff --git a/results/classifier/zero-shot/108/none/1392468 b/results/classifier/zero-shot/108/none/1392468 new file mode 100644 index 000000000..c0043a945 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1392468 @@ -0,0 +1,41 @@ +graphic: 0.516 +device: 0.443 +semantic: 0.401 +performance: 0.378 +other: 0.277 +permissions: 0.265 +socket: 0.253 +files: 0.206 +boot: 0.177 +network: 0.163 +PID: 0.158 +vnc: 0.129 +debug: 0.082 +KVM: 0.038 + +qemu uses a bitmap icon + +qemu currently uses the icon in pc-bios/qemu-icon.bmp, which, obviously, is a bitmap file. It is loaded such that white pixels will be transparent. This can cause nasty artifacts in the display. + +Unless there is a specific reason to use bitmaps, I'd suggest moving to, e.g., a PNG file with a proper alpha channel. + +For me the icon looks ugly if QEMU is run by the normal user. However, when run via sudo, it looks normal for some reason and does not display any of the white pixels. + +I also see an ugly icon when running QEMU as a user in GNOME. I tried running QEMU as root to see if there is any difference, but it doesn't work at all. I think QEMU should use pc-bios/qemu_logo_no_text.svg instead of pc-bios/qemu-icon.bmp. + +Gees, some please fix this already! Ubuntu 16.04.2 also uses some ugly icon. Why not ditch the bitmaps and use this official svg? + +http://git.qemu.org/?p=qemu.git;a=blob_plain;f=pc-bios/qemu_logo_no_text.svg;hb=HEAD + + + +On Ubuntu 18.04 and this is still an issue. + +Please don't make QEMU look like a crappy piece of software. It deserves a crisp icon. + +This series gives the QEMU SDL2 & GTK frontends high quality icons http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg04475.html + + +Finally fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a442fe2f2b2f20e7be0 + diff --git a/results/classifier/zero-shot/108/none/1393 b/results/classifier/zero-shot/108/none/1393 new file mode 100644 index 000000000..08a51eca5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1393 @@ -0,0 +1,80 @@ +other: 0.456 +vnc: 0.418 +permissions: 0.391 +graphic: 0.370 +performance: 0.363 +network: 0.357 +KVM: 0.353 +device: 0.350 +semantic: 0.346 +PID: 0.341 +debug: 0.336 +boot: 0.322 +files: 0.269 +socket: 0.238 + +Abort in audio_calloc() of ac97 +Description of problem: +Section 5.10.2 of the AC97 specification (https://hands.com/~lkcl/ac97_r23.pdf) +shows the feasibility to support for rates other than 48kHZ. Specifically, +AC97_PCM_Front_DAC_Rate (reg 2Ch) should be from 8kHZ to 48kHZ. + + +An adversary can leverage this to crash QEMU. + +A nornal 48kHZ setting is like this. + +``` +ac97_realize + open_voice + as->freq = 0xbb80 # 0xbb80=48000 + AUD_open_out + audio_pcm_create_voice_pair_out (sw is NULL) + audio_pcm_sw_init_out + sw->info.freq = as->freq (in audio_pcm_init_info()) + sw->ratio = ((int64_t) sw->hw->info.freq << 32) / sw->info.freq + samples = ((int64_t) sw->HWBUF->size << 32) / sw->ratio (in audio_pcm_sw_alloc_resources_out()) +``` + +A non-48kHZ setting is like this. Since `as->freq` is too small, `sw->ratio` is +too large. Finally, `samples` is zero, failing the audio_calloc() in +audio_pcm_sw_alloc_resources_out(). + +``` +nam_writew + open_voice + as->freq = 0x6 + AUD_open_out + audio_pcm_sw_init_out (sw is not NULL) + sw->info.freq = as->freq (in audio_pcm_init_info()) + sw->ratio = ((int64_t) sw->hw->info.freq << 32) / sw->info.freq + samples = ((int64_t) sw->HWBUF->size << 32) / sw->ratio (in audio_pcm_sw_alloc_resources_out()) + audio_calloc(.., samples, ) (in audio_pcm_sw_alloc_resources_out()) +``` +Steps to reproduce: +1. download the prepared rootfs and the image. + + https://drive.google.com/file/d/1IfVCvn76HY-Eb4AZU7yvuyPzM3QC1q10/view?usp=sharing + https://drive.google.com/file/d/1JN6JgvOSI5aSLIdTEFKiskKbrGWFo0BO/view?usp=sharing + +2. run the following script. + +``` bash +QEMU_PATH=../../../qemu-devel/build/x86_64-softmmu/qemu-system-x86_64 +KERNEL_PATH=./bzImage +ROOTFS_PATH=./rootfs.ext2 +$QEMU_PATH \ + -M q35 -m 1G \ + -kernel $KERNEL_PATH \ + -drive file=$ROOTFS_PATH,if=virtio,format=raw \ + -append "root=/dev/vda console=ttyS0" \ + -net nic,model=virtio -net user \ + -device ac97,audiodev=snd0 -audiodev none,id=snd0 \ + -nographic +``` + +3. with spawned shell (the user is root and the password is empty), run +`ac97-00`. +Additional information: +In the latest QEMU, this issue was generally fixed by 12f4abf6a245c43d8411577fd400373c85f08c6b and 0cbc8bd4694f32687bf47c6da48efa48fac35fd2 that remove abort() from the source code. Even though, I still plan to send a +patch so that the warning about the invalid freq will be gone. diff --git a/results/classifier/zero-shot/108/none/1396497 b/results/classifier/zero-shot/108/none/1396497 new file mode 100644 index 000000000..b5854e07f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1396497 @@ -0,0 +1,102 @@ +permissions: 0.476 +PID: 0.464 +device: 0.444 +other: 0.422 +files: 0.328 +graphic: 0.272 +socket: 0.243 +boot: 0.232 +semantic: 0.196 +vnc: 0.196 +performance: 0.182 +KVM: 0.181 +debug: 0.163 +network: 0.116 + +'qemu-img snapshot' allows new snapshot to be created with the name of an existing snapshot + +qemu-img _may_ be working as designed, but it feels like this could be a bug. I'd certainly prefer to only allow unique snapshot names (unless maybe something like a "--force-non-unique-snapshot-names" was also specified). + +If this really is correct behaviour, it should be documented as qemu-img(1) currently specifies no details whatsoever regarding expected behaviour or valid snapshot names. + +$ qemu-img snapshot -l image.cow +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +$ + +Note also how snapshot deletion works in reverse order - the oldest snapshot with a given name is deleted first. + +ProblemType: Bug +DistroRelease: Ubuntu 15.04 +Package: qemu-utils 2.1+dfsg-4ubuntu9 +ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7 +Uname: Linux 3.16.0-25-generic x86_64 +ApportVersion: 2.14.7-0ubuntu10 +Architecture: amd64 +CurrentDesktop: Unity +Date: Wed Nov 26 08:28:16 2014 +InstallationDate: Installed on 2014-04-11 (228 days ago) +InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140409) +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + kvm-irqfd-clean S< 0 0 719 2 0.0 [kvm-irqfd-clean] +MachineType: LENOVO 20AQCTO1WW +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-25-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 +SourcePackage: qemu +UpgradeStatus: Upgraded to vivid on 2014-05-08 (201 days ago) +dmi.bios.date: 02/10/2014 +dmi.bios.vendor: LENOVO +dmi.bios.version: GJET71WW (2.21 ) +dmi.board.asset.tag: Not Available +dmi.board.name: 20AQCTO1WW +dmi.board.vendor: LENOVO +dmi.board.version: 0B98405 STD +dmi.chassis.asset.tag: No Asset Information +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Not Available +dmi.modalias: dmi:bvnLENOVO:bvrGJET71WW(2.21):bd02/10/2014:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvr0B98405STD:cvnLENOVO:ct10:cvrNotAvailable: +dmi.product.name: 20AQCTO1WW +dmi.product.version: ThinkPad T440s +dmi.sys.vendor: LENOVO + + + +I'd agree that at least the last part - removing the oldest snapshot first - seems like a bug. + +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.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1426472 b/results/classifier/zero-shot/108/none/1426472 new file mode 100644 index 000000000..f43d7d822 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1426472 @@ -0,0 +1,53 @@ +boot: 0.579 +graphic: 0.565 +device: 0.387 +performance: 0.382 +PID: 0.200 +semantic: 0.199 +socket: 0.174 +permissions: 0.160 +other: 0.138 +files: 0.122 +vnc: 0.118 +network: 0.111 +debug: 0.101 +KVM: 0.018 + +Recent regression: segfault on startup with -snapshot + +As of git revision 041ccc922ee474693a2869d4e3b59e920c739bc0, qemu segfaults on startup when I try to boot a hard disk image with the -snapshot option. + +To reproduce: + + wget http://wiki.qemu.org/download/linux-0.2.img.bz2 + bunzip2 linux-0.2.img.bz2 + qemu-system-i386 -hda linux-0.2.img -snapshot + +When I run this, qemu-system-i386 crashes with a segmentation fault. This is on a Debian 7 amd64 host. + +git bisect implicates the following commit: + +commit a464982499b2f637f6699e3d03e0a9d2e0b5288b +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 11 17:15:18 2015 +0100 + + rcu: run RCU callbacks under the BQL + + This needs to go away sooner or later, but one complication is the + complex VFIO data structures that are modified in instance_finalize. + Take a shortcut for now. + + Reviewed-by: Michael Roth <email address hidden> + Tested-by: Michael Roth <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +I believe this was resolved in: + +commit 6b49809c597331803ea941eadda813e5bb4e8fe2 +Author: Paolo Bonzini <email address hidden> +Date: Fri Feb 27 19:58:23 2015 +0100 + + cpus: fix deadlock and segfault in qemu_mutex_lock_iothread + +The problem cannot be reproduced in qemu.git/master (fc85cf4a8199a657fdfd5fb902f1835973406454). + diff --git a/results/classifier/zero-shot/108/none/1429313 b/results/classifier/zero-shot/108/none/1429313 new file mode 100644 index 000000000..12e9d1349 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1429313 @@ -0,0 +1,30 @@ +device: 0.389 +graphic: 0.286 +network: 0.262 +performance: 0.242 +socket: 0.231 +semantic: 0.163 +PID: 0.109 +permissions: 0.096 +vnc: 0.096 +boot: 0.087 +debug: 0.087 +files: 0.053 +KVM: 0.034 +other: 0.031 + +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/zero-shot/108/none/1438572 b/results/classifier/zero-shot/108/none/1438572 new file mode 100644 index 000000000..24dd71662 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1438572 @@ -0,0 +1,36 @@ +device: 0.511 +graphic: 0.445 +semantic: 0.431 +other: 0.354 +performance: 0.335 +network: 0.306 +permissions: 0.223 +boot: 0.200 +socket: 0.181 +KVM: 0.165 +debug: 0.150 +vnc: 0.147 +PID: 0.112 +files: 0.091 + +kvm does not support KVM_CAP_USER_MEMORY Please upgrade to at least kernel 2.6.29 or recent kvm-kmod (see http://sourceforge.net/projects/kvm) + +We have a machine which is having QEMU+KVM on below configuration of linux +uname -a +Linux cairotrior 2.6.18-308.13.1.el5 #1 SMP Thu Jul 26 05:45:09 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux +cat /etc/issue +Red Hat Enterprise Linux Server release 5.8 (Tikanga) +Kernel \r on an \m + + +But in another setup, we are trying on a different machine having RHEL 5.9 having higher kernel version but it still gives below error +kvm does not support KVM_CAP_USER_MEMORY Please upgrade to at least kernel 2.6.29 or recent kvm-kmod (see http://sourceforge.net/projects/kvm). +failed to initialize KVM: Invalid argument No accelerator found! + + +I don’t know if the qemu version have compatibility issues with redhat 5.9 version – need someone to check if the qemu can run on redhat 5.9 64 bit or not ? + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +This error has never existed in QEMU, only in the old qemu-kvm fork which has been obsolete for about 5 years. I'm closing this ticket. + diff --git a/results/classifier/zero-shot/108/none/1440 b/results/classifier/zero-shot/108/none/1440 new file mode 100644 index 000000000..22a690bd5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1440 @@ -0,0 +1,16 @@ +network: 0.500 +device: 0.416 +socket: 0.407 +performance: 0.370 +semantic: 0.363 +vnc: 0.255 +PID: 0.239 +permissions: 0.231 +debug: 0.216 +graphic: 0.215 +boot: 0.121 +files: 0.089 +KVM: 0.070 +other: 0.066 + +block/curl.c uses curl features deprecated in curl 7.55.0 and 7.85.0 diff --git a/results/classifier/zero-shot/108/none/1446726 b/results/classifier/zero-shot/108/none/1446726 new file mode 100644 index 000000000..81b905433 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1446726 @@ -0,0 +1,54 @@ +KVM: 0.577 +other: 0.548 +performance: 0.515 +permissions: 0.498 +device: 0.465 +socket: 0.460 +vnc: 0.459 +files: 0.449 +debug: 0.447 +PID: 0.446 +semantic: 0.445 +network: 0.443 +graphic: 0.434 +boot: 0.428 + +qemu stable 2.0 crashes during loadvm + +Qemu output: + +2015-03-06 01:06:54.255+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/qemu-system-x86_64 -name instance-0000462a -S -machine pc-i440fx-trusty,accel=kvm,usb=off -cpu Westmere,+erms,+smep,+3dnowprefetch,+rdtscp,+rdrand,+tsc-deadline,+movbe,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 4096 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 7c3f225c-df2a-4014-997b-3200fcfff43d -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2014.1.2,serial=474aef35-d474-8001-e411-6108001017ac,uuid=7c3f225c-df2a-4014-997b-3200fcfff43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000462a.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 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,iops_rd=100,iops_wr=100 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/mapper/258c232d7056e0047,if=none,id=drive-virtio-disk1,format=raw,serial=dedb9d8d-e727-4d09-bf89-52e870125303,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/disk.config,if=none,id=drive-virtio-disk25,format=raw,cache=none,iops_rd=100,iops_wr=100 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk25,id=virtio-disk25 -chardev file,id=charserial0,path=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -k ja -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming fd:23 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 +char device redirected to /dev/pts/3 (label charserial1) +qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/memory.c:1403: memory_region_del_eventfd: Assertion `i != mr->ioeventfd_nb' failed. +2015-03-06 01:09:02.585+0000: shutting down + + +Libvirt log: +2015-03-05 11:29:48.434+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 00:13:33.077+0000: 8397: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping +2015-03-06 00:13:40.981+0000: 8397: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 00:14:27.206+0000: 8396: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 00:14:40.160+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 00:20:45.414+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 00:26:21.849+0000: 8396: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/25, skipping +2015-03-06 00:26:24.764+0000: 8396: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 00:28:09.425+0000: 8398: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 00:29:29.981+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 00:35:06.485+0000: 8398: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping +2015-03-06 00:35:09.645+0000: 8398: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 00:37:58.701+0000: 8397: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 00:59:12.925+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 01:04:57.990+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 01:05:18.031+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 01:05:37.954+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 01:06:13.213+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 01:06:29.870+0000: 8398: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping +2015-03-06 01:06:31.024+0000: 8398: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 01:06:57.274+0000: 8395: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 01:09:02.581+0000: 8392: error : qemuMonitorIORead:554 : Unable to read from monitor: Connection reset by peer + +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/zero-shot/108/none/1452062 b/results/classifier/zero-shot/108/none/1452062 new file mode 100644 index 000000000..ac4a4223a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1452062 @@ -0,0 +1,60 @@ +device: 0.211 +semantic: 0.179 +graphic: 0.081 +debug: 0.056 +other: 0.035 +socket: 0.029 +performance: 0.021 +PID: 0.019 +vnc: 0.013 +boot: 0.009 +network: 0.007 +permissions: 0.006 +files: 0.005 +KVM: 0.002 + +qemu-img will fail to convert images in 2.3.0 + +Hello guys, + + There seems to be a bug in qemu-img with 2.3.0 that wasn't there in 2.2.1 .... qemu convert will always fail converting. See the output below: + + +Started by upstream project "Create windows image" build number 73 +originally caused by: + Started by user anonymous +Building remotely on builder (builder lab) in workspace /var/lib/jenkins/remote/workspace/Prepare windows Image +[Prepare WS2008R2 Image] $ /bin/sh -xe /tmp/hudson4138890034689910617.sh ++ sudo bash -x /var/images/prepare_windows.sh WS2008R2 ++ set +x + +Preparing: windows +Virtio CD: virtio-win-0.1.96.iso + +Sparsifying... +qemu-img: error while compressing sector 11131648: Input/output error +virt-sparsify: error: external command failed: qemu-img convert -f +qcow2 -O 'qcow2' -c -o 'compat=0.10' '/tmp/sparsifyb459a0.qcow2' +'/var/images/generated/WS2008R2.qcow2' + +virt-sparsify: If reporting bugs, run virt-sparsify with debugging +enabled (-v) and include the complete output. +Build step 'Execute shell' marked build as failure +Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered +Finished: FAILURE + +Thanks, +Dave + +I can't reproduce this. qemu-img convert works just fine here. + +qemu-img convert -f qcow2 -O qcow2 -c -o compat=0.10 x.img y.img + +(from a random winXP guest image). + +The only possibly relevant change I can see in 2.3 is that the qcow2 driver added an additional error check to a truncate operation. Can you please run qemu-img under strace -f and either provide the output as an attachment or paste the relevant failing call(s) if you can recognise them? + +I rolled back QEMU to 2.2.1 and it succeeded converting the image ... I'll try to see if I can re-upgrade QEMU without breaking again the CI we have here. + +This problem is fixed with commit 3e5feb62 ("qcow2: Handle EAGAIN returned from update_refcount"), which will be included in qemu 2.4.0. + diff --git a/results/classifier/zero-shot/108/none/1452742 b/results/classifier/zero-shot/108/none/1452742 new file mode 100644 index 000000000..78daadc57 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1452742 @@ -0,0 +1,50 @@ +device: 0.290 +semantic: 0.231 +graphic: 0.188 +other: 0.169 +network: 0.165 +socket: 0.148 +PID: 0.109 +performance: 0.103 +permissions: 0.100 +vnc: 0.099 +debug: 0.057 +files: 0.057 +boot: 0.054 +KVM: 0.049 + +the option for vdagent communication needed for qxl scren resizing is not documented + +Hello, + +I tried running a guest with vdagent which is supposed to resize the guest screen to match client window size. + +However, a special serial port needs to be created for the vdagent to communicate with the client. + +This patch adds a short note to the vga qxl option. + + + +To be able to include your patch, you've got to send it to the qemu-devel mailing list, with a proper Signed-off-by line. Please see http://qemu-project.org/Contribute/SubmitAPatch#Submitting_your_Patches for details. + +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/424 + + diff --git a/results/classifier/zero-shot/108/none/1453 b/results/classifier/zero-shot/108/none/1453 new file mode 100644 index 000000000..d592b7f98 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1453 @@ -0,0 +1,16 @@ +semantic: 0.580 +other: 0.547 +graphic: 0.371 +device: 0.140 +performance: 0.112 +boot: 0.085 +KVM: 0.057 +permissions: 0.056 +debug: 0.037 +PID: 0.032 +network: 0.024 +vnc: 0.013 +socket: 0.010 +files: 0.006 + +Tricore: different definitions of pcxi register field diff --git a/results/classifier/zero-shot/108/none/1457275 b/results/classifier/zero-shot/108/none/1457275 new file mode 100644 index 000000000..980a5095a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1457275 @@ -0,0 +1,124 @@ +other: 0.587 +vnc: 0.586 +graphic: 0.539 +KVM: 0.528 +device: 0.481 +performance: 0.480 +permissions: 0.456 +debug: 0.454 +semantic: 0.438 +PID: 0.418 +socket: 0.400 +network: 0.393 +files: 0.383 +boot: 0.378 + +qemu-user hangs in m{,un}map loop + +Gentoo amd64 there, tried both 2.3.0 and eba05e922e8e7f307bc5d4104a78797e55124e97 versions of qemu. Reproduces with qemu-x86_64 as well. + +∞ strace qemu-arm bin/true 2>&1| head -n 100 +execve("/usr/bin/qemu-arm", ["qemu-arm", "bin/true"], [/* 49 vars */]) = 0 +uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 +brk(0) = 0x62a4d070 +brk(0x62a4e2b0) = 0x62a4e2b0 +arch_prctl(ARCH_SET_FS, 0x62a4d980) = 0 +set_tid_address(0x62a4dc50) = 7841 +set_robust_list(0x62a4dc60, 24) = 0 +rt_sigaction(SIGRTMIN, {0x6011bd10, [], SA_RESTORER|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 +rt_sigaction(SIGRT_1, {0x6011bda0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 +rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 +getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +readlink("/proc/self/exe", "/usr/bin/qemu-arm", 4096) = 17 +brk(0x62a6f2b0) = 0x62a6f2b0 +brk(0x62a70000) = 0x62a70000 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 +mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x2c951ff9000 +mprotect(0x2c951ff9000, 4096, PROT_NONE) = 0 +clone(child_stack=0x2c9527f8df0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x2c9527f99d0, tls=0x2c9527f9700, child_tidptr=0x2c9527f99d0) = 7842 +rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 +gettimeofday({1432174351, 569148}, NULL) = 0 +getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +time(NULL) = 1432174351 +openat(AT_FDCWD, "/usr/gnemul/qemu-arm", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) +uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 +mprotect(0x60519000, 33558528, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 +madvise(0x605190b0, 33554432, MADV_HUGEPAGE) = -1 EINVAL (Invalid argument) +mmap(NULL, 50331648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c94eff9000 +brk(0x62a91000) = 0x62a91000 +mmap(NULL, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x1000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x2000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x3000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x4000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x5000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x6000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x7000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x8000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x9000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xa000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xb000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xc000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xd000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xe000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xf000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x10000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x11000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 + +This works for me so I think we must have fixed this problem at some point between 2.3 and current master. If you still have this problem with a QEMU build from head of git please reopen with instructions for how to reproduce. + + diff --git a/results/classifier/zero-shot/108/none/1462944 b/results/classifier/zero-shot/108/none/1462944 new file mode 100644 index 000000000..a1bd29268 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1462944 @@ -0,0 +1,44 @@ +performance: 0.548 +graphic: 0.437 +device: 0.396 +semantic: 0.383 +other: 0.236 +PID: 0.198 +vnc: 0.103 +socket: 0.094 +network: 0.091 +debug: 0.074 +permissions: 0.058 +files: 0.055 +boot: 0.041 +KVM: 0.028 + +vpc file causes qemu-img to consume lots of time and memory + +The attached vpc file causes 'qemu-img info' to consume 3 or 4 seconds of CPU time and 1.3 GB of heap, causing a minor denial of service. + +$ /usr/bin/time ~/d/qemu/qemu-img info afl12.img +block-vpc: The header checksum of 'afl12.img' is incorrect. +qemu-img: Could not open 'afl12.img': block-vpc: free_data_block_offset points after the end of file. The image has been truncated. +1.19user 3.15system 0:04.35elapsed 99%CPU (0avgtext+0avgdata 1324504maxresident)k +0inputs+0outputs (0major+327314minor)pagefaults 0swaps + +The file was found using american-fuzzy-lop. + + + +This slightly modified example takes about 7 seconds and 2 GB of heap: + +$ /usr/bin/time ~/d/qemu/qemu-img info /mnt/scratch/afl13.img +block-vpc: The header checksum of '/mnt/scratch/afl13.img' is incorrect. +qemu-img: Could not open '/mnt/scratch/afl13.img': block-vpc: free_data_block_offset points after the end of file. The image has been truncated. +1.84user 5.72system 0:07.59elapsed 99%CPU (0avgtext+0avgdata 2045496maxresident)k +8inputs+0outputs (0major+507536minor)pagefaults 0swaps + + +Is there still something left to do here, or could we close this ticket nowadays? + +I suspect this bug is probably still around, and if not then this class of bugs is certainly still around. What we have done in management tools like Open Stack is to confine qemu-img using simple ulimits when inspecting any untrusted image, and that solves the problem so it's probably fine to close this bug now. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1469978 b/results/classifier/zero-shot/108/none/1469978 new file mode 100644 index 000000000..e2446ca73 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1469978 @@ -0,0 +1,55 @@ +device: 0.366 +other: 0.330 +semantic: 0.321 +graphic: 0.284 +PID: 0.270 +KVM: 0.204 +files: 0.179 +vnc: 0.155 +socket: 0.152 +permissions: 0.146 +network: 0.143 +performance: 0.134 +boot: 0.122 +debug: 0.106 + +compile qemu use with KVM machine not supported + +I have to compile qemu 2.3.0 and 2.2.0. and install follow this. + ./configure --enable-kvm --target-list=x86_64-softmmu + make + make install +It's located in /usr/local/bin +I want to use qemu with KVM so I copy /usr/local/bin/qemu-system-x86_64 to /usr/bin + +and I run VMM for start my VM. + + + +---------------------------------------------------------------------------------------------------------------------------------------------------------------------- +Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6: Unsupported machine type +Use -machine help to list supported machines! + + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1162, in startup + self._backend.create() + File "/usr/lib/python2.7/dist-packages/libvirt.py", line 866, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: internal error: process exited while connecting to monitor: qemu-system-x86_64: -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6: Unsupported machine type +Use -machine help to list supported machines! + +---------------------------------------------------------------------------------------------------------------------------------------------------------------------- + +I can't use my VM except reinstall kvm, qemu-kvm. + + + +What kind of Linux distribution are you using? Sound like you're using libvirt on top of QEMU ... how does your guest XML definition in libvirt look like? You might need to specify a different machine type in your XML there... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1480 b/results/classifier/zero-shot/108/none/1480 new file mode 100644 index 000000000..195cac64f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1480 @@ -0,0 +1,16 @@ +semantic: 0.509 +graphic: 0.409 +performance: 0.344 +KVM: 0.110 +other: 0.108 +boot: 0.101 +debug: 0.084 +vnc: 0.045 +permissions: 0.035 +PID: 0.016 +socket: 0.015 +device: 0.015 +network: 0.004 +files: 0.002 + +-cpu <whatever>,help should print the options available for that CPU type diff --git a/results/classifier/zero-shot/108/none/1481654 b/results/classifier/zero-shot/108/none/1481654 new file mode 100644 index 000000000..d035860f6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1481654 @@ -0,0 +1,56 @@ +device: 0.469 +PID: 0.414 +permissions: 0.401 +files: 0.397 +graphic: 0.374 +KVM: 0.373 +socket: 0.363 +network: 0.328 +boot: 0.287 +other: 0.244 +semantic: 0.191 +vnc: 0.182 +performance: 0.159 +debug: 0.106 + +libcacard.pc paths are not modified when configure prefix is + +Ubuntu Server 15.04 Gnome +Qemu sources from master git://git.qemu-project.org/qemu.git 2.4.0-rc3 SHA 2be4f242 + +Built with: +make distclean +./configure --target-list=x86_64-softmmu \ + --cpu=x86_64 \ + --enable-virtfs \ + --enable-kvm \ + --enable-spice \ + --enable-usb-redir \ + --enable-libusb \ + --audio-drv-list=oss,alsa,sdl,pa \ + --enable-uuid \ + --enable-libnfs \ + --enable-libssh2 \ + --prefix=/usr --sysconfdir=/etc --localstatedir=/var + +make -j6 + +Yet, /usr/lib/libcacard.pc: +prefix=/usr/local +exec_prefix=${prefix} +libdir=/usr/local/lib +includedir=/usr/local/include/cacard + +Name: cacard +Description: CA Card library +Version: 2.3.50 + +Requires.private: nss glib-2.0 +Libs: -L${libdir} -lcacard +Libs.private: +Cflags: -I${includedir} + +This issue affects the building of spice-client-gtk (http://cgit.freedesktop.org/spice/spice-gtk/) which expects correct paths in that file. + +Since QEMU 2.5, libcacard is now an external project (see http://www.spice-space.org/page/Libcacard), so this should not be a problem anymore. + diff --git a/results/classifier/zero-shot/108/none/1481990 b/results/classifier/zero-shot/108/none/1481990 new file mode 100644 index 000000000..c411ff3b6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1481990 @@ -0,0 +1,57 @@ +device: 0.563 +graphic: 0.510 +debug: 0.476 +PID: 0.475 +semantic: 0.432 +files: 0.431 +performance: 0.391 +permissions: 0.375 +other: 0.331 +network: 0.300 +socket: 0.289 +boot: 0.235 +vnc: 0.202 +KVM: 0.119 + +2.3.0 build fails on Ubuntu 12.04 + +Build of 2.3.0 fails on Ubuntu 12.04: + +sudo make clean +sudo ./configure --prefix=/usr/local --target-list=i386-softmmu,arm-softmmu,x86_64-softmmu +sudo make + + GEN config-host.h + GEN qemu-options.def + GEN qmp-commands.h + GEN qapi-types.h + GEN qapi-visit.h + GEN qapi-event.h + GEN trace/generated-events.h + GEN trace/generated-tracers.h + ... + + CC migration/qemu-file-stdio.o + CC migration/xbzrle.o + CC migration/rdma.o +migration/rdma.c: In function ‘qemu_rdma_dump_id’: +migration/rdma.c:706:21: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:707:22: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:707:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) +migration/rdma.c:707:37: note: each undeclared identifier is reported only once for each function it appears in +migration/rdma.c:708:24: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:708:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) +migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’: +migration/rdma.c:800:26: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:800:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) +migration/rdma.c:802:33: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:802:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) +migration/rdma.c:841:18: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +make: *** [migration/rdma.o] Error 1 + +Build succeeds with + +sudo ./configure --prefix=/usr/local --target-list=i386-softmmu,arm-softmmu,x86_64-softmmu --disable-rdma + +This does not happend anymore with the upstream git. Closing. Please reopen if you still see this. + diff --git a/results/classifier/zero-shot/108/none/1486911 b/results/classifier/zero-shot/108/none/1486911 new file mode 100644 index 000000000..56c3472fd --- /dev/null +++ b/results/classifier/zero-shot/108/none/1486911 @@ -0,0 +1,79 @@ +other: 0.220 +permissions: 0.199 +graphic: 0.196 +semantic: 0.179 +KVM: 0.175 +files: 0.169 +PID: 0.161 +network: 0.157 +device: 0.153 +debug: 0.151 +performance: 0.144 +socket: 0.133 +vnc: 0.133 +boot: 0.118 + +Error compilation qemu 2.3.1 on raspberry pi (RASPBIAN(debian)) + +When compiling from source occurs to me incomprehensible error. +Operation ./configure runs without problems, but among the logs make see this: + CP i386-softmmu / hw / i386 / acpi-dsdt.hex + CP i386-softmmu / hw / i386 / q35-acpi-dsdt.hex + CP i386-softmmu / hw / i386 / ssdt-tpm.hex + CC i386-softmmu / target-i386 / translate.o + CC m68k-softmmu / tcg / tcg-op.o + CC m68k-softmmu / tcg / optimize.o +In file included from /home/pi/Zagruzki/qemu-2.3.1/include/qapi/error.h:16:0, + from /home/pi/Zagruzki/qemu-2.3.1/include/qemu/option.h:31, + from /home/pi/Zagruzki/qemu-2.3.1/include/qemu-common.h:44, + from /home/pi/Zagruzki/qemu-2.3.1/tcg/optimize.c:31: +/home/pi/Zagruzki/qemu-2.3.1/qapi-types.h:196:8: error: unknown type name '$ uint64_t' +/home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «tcg / optimize.o» +make [1]: *** [tcg / optimize.o] Error 1 +Makefile: 173: error is the recipe for the purpose of «subdir-m68k-softmmu» +make: *** [subdir-m68k-softmmu] Error 2 +make: *** Waiting for jobs ... + +When you try to create a package using checkinstall is such error: +/home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c: In function 'helper_msa_copy_s_df': +/home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: error: unrecognizable insn: +(insn 123 122 124 3 (set (subreg: SI (reg: DI 169) 0) + (sign_extend: SI (mem / s / j: QI (plus: SI (reg: SI 167) + (const_int 440 [0x1b8])) [0 env_8 (D) -> active_fpu.fpr [ws_9 (D)]. wr.b S1 A8]))) /home/pi/Zagruzki/qemu-2.3.1/target- mips / msa_helper.c: 1253 -1 + (nil)) +/home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: internal compiler error: in extract_insn, at recog.c: 2109 +Please submit a full bug report, +with preprocessed source if appropriate. +See <file: ///usr/share/doc/gcc-4.6/README.Bugs> for instructions. +Preprocessed source stored into /tmp/cc1quRqL.out file, please attach this to your bugreport. +/home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «target-mips / msa_helper.o» +make [1]: *** [target-mips / msa_helper.o] Error 1 +Makefile: 173: error is the recipe for the purpose of «subdir-mips64-softmmu» +make: *** [subdir-mips64-softmmu] Error 2 + +**** Installation unsuccessful. It cancels the creation of the package. + +Cleared ... OK + +Good luck. + +Log make, checkinstall from the terminal http://rghost.ru/7SK6y4bs6 +cc1quRqL.out applications + + + +Can you try the latest upstream git version from: https://github.com/qemu/qemu? + +Also can you post your configure command line? + +The part about: + error: unrecognizable insn: +(insn 123 122 124 3 (set (subreg: SI (reg: DI 169) 0) + (sign_extend: SI (mem / s / j: QI (plus: SI (reg: SI 167) + (const_int 440 [0x1b8])) [0 env_8 (D) -> active_fpu.fpr [ws_9 (D)]. wr.b S1 A8]))) + +is either (a) a compiler bug or (b) a hardware bug (bad memory, bad disk, etc) causing the compiler to blow up. + + +This is definitely not a QEMU bug, so closing this now. You should either try a different version of GCC, or check the hardware of your Pi. + diff --git a/results/classifier/zero-shot/108/none/1496 b/results/classifier/zero-shot/108/none/1496 new file mode 100644 index 000000000..99c3f4a13 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1496 @@ -0,0 +1,42 @@ +graphic: 0.450 +performance: 0.418 +device: 0.211 +PID: 0.210 +socket: 0.180 +vnc: 0.150 +permissions: 0.145 +other: 0.089 +semantic: 0.088 +network: 0.075 +files: 0.073 +boot: 0.073 +debug: 0.067 +KVM: 0.026 + +Multiple issues detected by the thread sanitizer build +Description of problem: +Switching the tsan build in the CI from benchmark to check-unit revealed a bunch of issues even in our most basic tests. +Steps to reproduce: +1. configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +2. make check-unit +3. recoil in horror at the failures +Additional information: +From: https://gitlab.com/stsquad/qemu/-/jobs/3779216892 + +``` +Summary of Failures: +27/95 qemu:unit / rcutorture ERROR 3.83s exit status 66 +28/95 qemu:unit / test-rcu-list ERROR 5.28s exit status 66 +29/95 qemu:unit / test-rcu-simpleq ERROR 5.07s exit status 66 +30/95 qemu:unit / test-rcu-tailq ERROR 5.12s exit status 66 +32/95 qemu:unit / test-rcu-slist ERROR 5.07s exit status 66 +40/95 qemu:unit / test-logging ERROR 2.50s exit status 66 +52/95 qemu:unit / test-aio-multithread ERROR 9.53s exit status 66 +54/95 qemu:unit / test-thread-pool ERROR 7.22s exit status 66 +55/95 qemu:unit / test-bdrv-drain ERROR 2.37s exit status 66 +58/95 qemu:unit / test-blockjob ERROR 2.04s exit status 66 +60/95 qemu:unit / test-block-iothread ERROR 2.08s exit status 66 +74/95 qemu:unit / test-io-channel-command ERROR 0.10s killed by signal 13 SIGPIPE +90/95 qemu:unit / test-replication ERROR 25.03s exit status 66 +93/95 qemu:unit / test-util-filemonitor ERROR 2.61s exit status 66 +``` diff --git a/results/classifier/zero-shot/108/none/1502613 b/results/classifier/zero-shot/108/none/1502613 new file mode 100644 index 000000000..70bea81f3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1502613 @@ -0,0 +1,57 @@ +device: 0.586 +semantic: 0.548 +performance: 0.472 +PID: 0.462 +other: 0.392 +graphic: 0.346 +vnc: 0.335 +permissions: 0.292 +boot: 0.281 +files: 0.280 +socket: 0.265 +KVM: 0.247 +network: 0.244 +debug: 0.204 + +[Feature Request] Battery Status / Virtual Battery + +When using virtualization on notebooks heavily then virtual machines do not realize that they're running on a notebook device causing high power consumption because they're not switching into a optimized "laptop mode". This leads to the circumstance that they are trying to do things like defragmentation / virtus scan / etc. while the host is still running on batteries. + +So it would be great if QEMU / KVM would have support for emulating "Virtual Batteries" to guests causing them to enable power-saving options like disabling specific services / devices / file operations automatically by OS. + +Optionally a great feature would be to set virtual battery's status manually. For example: Current charge rate / charging / discharging / ... + +I'm trying to add virtual battery to QEMU. More specifically, if the HOST is running on battery power [laptop] I want to pass this knowledge to GUEST. + +I have looked at ACPI folder within QEMU source code, however was unable to find the specific place where I can add this functionality. + +Can someone provide me with general roadmap of what should I do and where I should start? I suspect that changing the QEMU source code will not be enough and I will also have to implement a driver for the GUEST. + +I've started working on this issue and have some progress. Fedora 31 guest is already able to see a battery device but its state currently hardcoded. I think i will finish this in a few weeks. + +Has there been any progress? I'm using KVM for ubuntu 20.04 and would love to have this feature. + +The implementation could be similar to the temperature sensor interface proposed here: +https://<email address hidden>/msg65192.html + +mizz, + +I'm worked on it and got a working draft on pre-5.0 codebase. It can react on QMP property changes to trigger ACPI events on x86 and arm-virt. + +However i've stuck on frontend/backend split. Keep calm, i'm still working on the task and will complete this soon. + +Philippe, thanks for advice! + + +I just wanted to add that this would (probably) help solve the error 43 on mobile Nvidia GPU passthrough scenarios. While facing this myself I was able to get it working by simulating a battery and attaching it via an ACPI table. +Your work is greatly appreciated Sergey. +Thank you very much! + + +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/242 + + diff --git a/results/classifier/zero-shot/108/none/1502884 b/results/classifier/zero-shot/108/none/1502884 new file mode 100644 index 000000000..287be5774 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1502884 @@ -0,0 +1,62 @@ +KVM: 0.557 +permissions: 0.491 +vnc: 0.463 +semantic: 0.457 +network: 0.447 +other: 0.438 +graphic: 0.416 +device: 0.416 +debug: 0.414 +files: 0.390 +performance: 0.350 +socket: 0.301 +PID: 0.284 +boot: 0.235 + +Super important feature req: QEMU VNC server: Introduce a keyboard "norepeat" option! + +Hi, + +A big issue when using QEMU's VNC server (VNC KVM) is that, when there's a network lag, unintended keypresses go through to the QEMU guest VM. + +This is frequently "enter" keypresses, causing all kinds of unintended consequences in the VM. So basically it's extremely dangerous. + +This is because the VNC protocol's keyboard interaction is implemented in terms of key down - key up events, making the server's keyboard autorepeat kick in when it should not. + + +For this reason, it would be great if QEMU's VNC server part would be enhanced with an option such that when a VNC protocol key down is received, then locally that is treated as one single keypress only (I don't know how that should be implemented but I guess either as an immediate key down - key up sequence locally, or key down + key up after say 0.05 seconds), instead of waiting for the key up event from the VNC client. + +Thanks! + +What I request seems to be the same option as x11vnc's "-norepeat", http://linux.die.net/man/1/x11vnc + +... this doesn't seem to be a VNC-only issue.. I get quite the big of repeat/stuck key presses with the GTK frontend as well.. Also, lines like these frequently show up in the logs: + +> [15512.846716] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [15513.031586] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [15513.931140] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [15513.935319] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [15994.802058] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [15994.807817] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18243.163746] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18243.165704] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18243.372671] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18243.374203] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18576.754033] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18576.771257] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18584.556247] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18585.168172] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18628.989958] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18628.992058] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [20227.153135] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [20227.161066] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. + + +The VNC server doesn't get involved in key repeat functionality, it just passes keys from the client onto the guest OS. The client can indicate that it is doing key repeat by sending a series of "key down" events, and only 1 "key up" event to indicate end of auto-repeat. The guest OS can itself implement auto-repeat at any frequency it wishes by watching the key stream. The "-norepeat" option to X11 VNC that is referred to here isn't something related to the VNC part of x11vnc, but rather it appears related to the X11 part which corresponds to the guest OS in QEMU's case. I don't see there is much QEMU can do here. + +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/zero-shot/108/none/1509 b/results/classifier/zero-shot/108/none/1509 new file mode 100644 index 000000000..e48731a6c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1509 @@ -0,0 +1,176 @@ +other: 0.249 +graphic: 0.231 +device: 0.201 +permissions: 0.199 +semantic: 0.195 +performance: 0.188 +vnc: 0.184 +PID: 0.177 +boot: 0.176 +debug: 0.163 +network: 0.153 +KVM: 0.133 +socket: 0.119 +files: 0.090 + +ppc64 tcg guests get incorrect Capacity Entitlement values from SMP spapr machine's RTAS - examples given from AIX guest OS +Description of problem: +Entitled Capacity of the guest OS is not equal to the number of vCPUs you configure with QEMU. + +It only gives you 1/4 entitlements to your configured capacity, and if you increase the number of processors, it converts the LPAR capacity to hundredths of a core, throttling guest performance. +Steps to reproduce: +Definition of terms from lparstat: +Entitled Capacity: The number of processing units this LPAR is entitled to receive. +Maximum Capacity: The maximum number of processing units this LPAR was defined to ever have. Entitled capacity can be increased up to this value. + +Some examples: + +1 QEMU vCPU: +Entitled Capacity: 0.25 +Maximum Capacity: 1.00 + +2 QEMU vCPUs (-smp cpus=2,sockets=1,cores=2,threads=1): +Entitled Capacity = 0.50 +Maximum Capacity: 0.02 + +3 QEMU CPUs (-smp cpus=3,sockets=1,cores=3,threads=1): +Entitled Capacity = 0.75 +Maximum Capacity: 0.03 + +4 QEMU CPUs (-smp cpus=4,sockets=1,cores=4,threads=1): +Entitled Capacity = 1.00 +Maximum Capacity: 0.04 + +I believe these Entitled and Maximum values are comming from the spapr machine's MaxEntCap, DesProcs and MaxPlatProcs settings which get affected by -smp passed to QEMU. +Additional information: +Details: + +1 QEMU vCPU: + ``` +kens@aix-ppc64$ lparstat -i | head -20 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +Partition Number : 0 +Type : Shared +Mode : Capped +Entitled Capacity : 0.25 +Partition Group-ID : 1 +Shared Pool ID : 1 +Online Virtual CPUs : 1 +Maximum Virtual CPUs : 1 +Minimum Virtual CPUs : 1 +Online Memory : 8192 MB +Maximum Memory : 8192 MB +Minimum Memory : 8192 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.01 +Maximum Capacity : 1.00 +Capacity Increment : 1.00 +Maximum Physical CPUs in system : 1 +Active Physical CPUs in system : 1 + ``` +2 QEMU vCPUs: + ``` +kens@aix-ppc64$ lparstat -i | head -20 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +Partition Number : 0 +Type : Shared +Mode : Capped +Entitled Capacity : 0.50 +Partition Group-ID : 1 +Shared Pool ID : 1 +Online Virtual CPUs : 2 +Maximum Virtual CPUs : 2 +Minimum Virtual CPUs : 2 +Online Memory : 8192 MB +Maximum Memory : 8192 MB +Minimum Memory : 8192 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.02 +Maximum Capacity : 0.02 +Capacity Increment : 1.00 +Maximum Physical CPUs in system : 2 +Active Physical CPUs in system : 2 + ``` +3 QEMU vCPUs: + ``` +kens@aix-ppc64$ lparstat -i | head -20 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +Partition Number : 0 +Type : Shared +Mode : Capped +Entitled Capacity : 0.75 +Partition Group-ID : 1 +Shared Pool ID : 1 +Online Virtual CPUs : 3 +Maximum Virtual CPUs : 3 +Minimum Virtual CPUs : 3 +Online Memory : 8192 MB +Maximum Memory : 8192 MB +Minimum Memory : 8192 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.03 +Maximum Capacity : 0.03 +Capacity Increment : 1.00 +Maximum Physical CPUs in system : 3 +Active Physical CPUs in system : 3 + ``` +4 QEMU vCPUs: + ``` +kens@aix-ppc64$ lparstat -i | head -2 +lparstat -i | head -2 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +kens@aix-ppc64$ lparstat -i | head -20 +lparstat -i | head -20 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +Partition Number : 0 +Type : Shared +Mode : Capped +Entitled Capacity : 1.00 +Partition Group-ID : 1 +Shared Pool ID : 1 +Online Virtual CPUs : 4 +Maximum Virtual CPUs : 4 +Minimum Virtual CPUs : 4 +Online Memory : 8192 MB +Maximum Memory : 8192 MB +Minimum Memory : 8192 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.04 +Maximum Capacity : 0.04 +Capacity Increment : 1.00 +Maximum Physical CPUs in system : 4 +Active Physical CPUs in system : 4 + ``` +So it seems to me like the OS assumes the following from the spapr machine settings: +Entitled Capacity = cpus / 4 (OS is assuming smt=4 threads maybe, see below) +Maximim Capacity = cpus / 100 (OS is assuming hundredths of a core, even though the Capacity Increment is 1.00, see below)) + +On a real Power system (POWER8, smt=8), it looks like this: + ``` +kens@aix72$ lparstat -i | head -20 +Node Name : aix72 +Partition Name : n1 +Partition Number : 1 +Type : Shared-SMT-4 +Mode : Uncapped +Entitled Capacity : 6.00 +Partition Group-ID : 32784 +Shared Pool ID : 0 +Online Virtual CPUs : 12 +Maximum Virtual CPUs : 28 +Minimum Virtual CPUs : 1 +Online Memory : 131072 MB +Maximum Memory : 196608 MB +Minimum Memory : 1024 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.50 +Maximum Capacity : 14.00 +Capacity Increment : 0.01 +Maximum Physical CPUs in system : 80 +Active Physical CPUs in system : 80 + ``` diff --git a/results/classifier/zero-shot/108/none/1511 b/results/classifier/zero-shot/108/none/1511 new file mode 100644 index 000000000..7ae073098 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1511 @@ -0,0 +1,16 @@ +performance: 0.304 +boot: 0.278 +graphic: 0.241 +semantic: 0.167 +debug: 0.138 +permissions: 0.087 +vnc: 0.056 +other: 0.051 +device: 0.049 +KVM: 0.042 +socket: 0.031 +PID: 0.031 +files: 0.007 +network: 0.003 + +Please a CPU model for ABI version for x86_64 i386 according to x86-64 psABI diff --git a/results/classifier/zero-shot/108/none/1512134 b/results/classifier/zero-shot/108/none/1512134 new file mode 100644 index 000000000..795960cfe --- /dev/null +++ b/results/classifier/zero-shot/108/none/1512134 @@ -0,0 +1,57 @@ +device: 0.589 +graphic: 0.586 +other: 0.576 +semantic: 0.492 +boot: 0.432 +socket: 0.385 +performance: 0.377 +network: 0.300 +debug: 0.280 +vnc: 0.254 +files: 0.196 +PID: 0.143 +permissions: 0.101 +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/zero-shot/108/none/1513 b/results/classifier/zero-shot/108/none/1513 new file mode 100644 index 000000000..ca99bd9df --- /dev/null +++ b/results/classifier/zero-shot/108/none/1513 @@ -0,0 +1,16 @@ +performance: 0.367 +permissions: 0.337 +PID: 0.235 +boot: 0.228 +graphic: 0.170 +vnc: 0.169 +debug: 0.140 +device: 0.129 +semantic: 0.124 +KVM: 0.087 +other: 0.033 +socket: 0.011 +network: 0.005 +files: 0.000 + +CPU flags should be better documented diff --git a/results/classifier/zero-shot/108/none/1523 b/results/classifier/zero-shot/108/none/1523 new file mode 100644 index 000000000..647a79fe8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1523 @@ -0,0 +1,16 @@ +device: 0.587 +performance: 0.583 +semantic: 0.331 +other: 0.141 +boot: 0.131 +PID: 0.097 +graphic: 0.093 +vnc: 0.082 +network: 0.063 +debug: 0.048 +permissions: 0.046 +files: 0.038 +KVM: 0.029 +socket: 0.009 + +Tricore: no interrupts emulation diff --git a/results/classifier/zero-shot/108/none/1523246 b/results/classifier/zero-shot/108/none/1523246 new file mode 100644 index 000000000..731de43a9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1523246 @@ -0,0 +1,110 @@ +device: 0.579 +other: 0.566 +graphic: 0.551 +permissions: 0.550 +vnc: 0.529 +KVM: 0.526 +semantic: 0.519 +network: 0.501 +debug: 0.497 +PID: 0.491 +performance: 0.477 +files: 0.458 +boot: 0.450 +socket: 0.363 + +Virtio-blk does not support TRIM + +When model=virtio is used, TRIM is not supported. + +# mount -o discard /dev/vda4 /mnt +# mount | tail -1 +/dev/vda4 on /mnt type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096) +# fstrim /mnt/ +fstrim: /mnt/: the discard operation is not supported + +Booting without model=virtio allows using TRIM (in Windows as well). + +Full QEMU line: + +qemu-system-x86_64 -enable-kvm -cpu host -bios /usr/share/ovmf/ovmf_x64.bin -smp 2 -m 7G -vga qxl -usbdevice tablet -net nic,model=virtio -net user -drive discard=unmap,detect-zeroes=unmap,cache=none,file=vms/win10.hd.img.vmdk,format=vmdk,if=virtio + + + +Ideally there should be a warning if a user gives discard=unmap and isn't using the SCSI bus. Using the following options allows the guest to detect the drive as a thinly provisioned drive. + +-drive discard=unmap,detect-zeroes=unmap,cache=none,file=vms/win10.hd.img.vmdk,format=vmdk,if=none,id=hd -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd + + + +Virtio will never support discard requests. Please use virtio-scsi. + +So, please rename bug to "Feature request: Refuse to operate if virtio + discard is requested" + +> Virtio will never support discard requests. + + - what is that? + +> Please use virtio-scsi. + + - in some tests, SCSI emulation appears 7 times slower than the paravirtualized bus. + + +> Virtio will never support discard requests. + +Why? If you don't want to write a treatise on the subject, perhaps point at an LWN article or LKML thread where that conclusion was discussed or reached. + +> So, please rename bug to "Feature request: Refuse to operate if virtio + discard is requested" + +Uh, if the feature as requested will never be satisfied, WONTFIX it and create a feature that could be satisfied. Or WONTFIX it and take no further action. Either way, the status of things would be much clearer to use poor schmucks who land here googling the issue. + +discard support for virtio-blk is on the QEMU TODO list: + +http://wiki.qemu-project.org/ToDo/Block#virtio-blk_discard_support_.5BPeter_Lieven.5D + +Granted, it's been there since October of 2014. http://wiki.qemu-project.org/index.php?title=ToDo/Block&oldid=4410#virtio-blk_discard_support_.5BPeter_Lieven.5D + +I believe this feature was just merged by Linus about a week ago, and is in linux 5.0-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d548e65904ae43b0637d200a2441fc94e0589c30 + +While the Linux virtio-blk guest driver now supports discard and write zeroes, QEMU's virtio-blk device emulation does not support it yet. + +The DISCARD feature has now been implemented in QEMU, too: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=37b06f8d46fe602e630e4 + +On which version of qemu the discard option is supported? + +I have emulated a VM with below qemu options related to disk type: + +-drive file=disk.img,if=none,id=disk0,l2-cache-size=8M,format=qcow2,discard=on,detect-zeroes=unmap,aio=io_uring -device virtio-blk-pci,drive=disk0,scsi=off,bootindex=2 + +the disk file on the host side is located on xfs mountpoint on RAID level 10 array. + +After I downloaded a file with 1GB size on the guest OS, I saw the size of the disk file on the host has been increased as well. + +But when I delete the downloaded file and issue fstrim --all -v command, the disk file on host has not been decreased. + +The version of qemu I'm using is 5.2.0 + +$ git tag --contains 37b06f8d46fe602e630e4 | grep ^v | sort | head -n1 +v4.0.0 + +How did you check the size of the file? It might appear bigger than it is due to sparse blocks. + +I've checked the size of disk file with ls -alh and du --apparent-size commands + +I downloaded the 1G size file 5 times to make sure about sparse blocks issue, but the problem still exists + +I think you should check with "du" but without "--apparent-size" since that parameter counts the sparse blocks, too. See e.g.: + +$ truncate -s 10M test.dat +$ ls -alh test.dat +-rw-rw-r--. 1 root root 10M Dec 12 14:31 test.dat +$ du -sh --apparent-size test.dat +10M test.dat +$ du -sh test.dat +0 test.dat + + + +thanks. so now my question is that are these sparsed blocks rewritable? I mean after deletion of a file and downloading again, will these files be stored on the sparsed blocks or the number of starting block for write operation will be after the number of latest sparsed block? + diff --git a/results/classifier/zero-shot/108/none/1528718 b/results/classifier/zero-shot/108/none/1528718 new file mode 100644 index 000000000..f32ea4598 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1528718 @@ -0,0 +1,56 @@ +semantic: 0.342 +device: 0.216 +graphic: 0.205 +PID: 0.179 +files: 0.159 +socket: 0.141 +other: 0.130 +boot: 0.081 +permissions: 0.072 +performance: 0.068 +vnc: 0.067 +network: 0.058 +debug: 0.047 +KVM: 0.009 + +Initial monitor does not output anything on Windows (MSYS2 binary) + +When running on Windows error messages before the UI is started are not showing up. + +For example when I run: + +qemu-system-i386.exe -L /mingw32/etc/qemu/ -m 20G + +It should display "ram size too large", according to gdb: + +Breakpoint 1, error_report (fmt=fmt@entry=0x71bdf6 <dma_aiocb_info+2426> "ram size too large") at C:/build/mingw/mingw-w64-qemu/src/qemu-2.4.0/util/qemu-error.c:233 + +However the console does never receive that. + +As far as I could find out vfprintf is called, but it doesn't output anything. + +This affects both binary editions (for instance "qemu-system-i386.exe" AND "qemu-system-i386w.exe") + +dumpbin /all "C:\Program Files\qemu\qemu-system-i386.exe"|more +Dump of file C:\Program Files\qemu\qemu-system-i386.exe +PE signature found +File Type: EXECUTABLE IMAGE +FILE HEADER VALUES +8664 machine (x64) + +This affects both binary editions (for instance "qemu-system-i386.exe" AND "qemu-system-i386w.exe") + +dumpbin /all "C:\Program Files\qemu\qemu-system-i386.exe"|more +Dump of file C:\Program Files\qemu\qemu-system-i386.exe +PE signature found +File Type: EXECUTABLE IMAGE +4.00 operating system version +5.02 subsystem version: Win32 + + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +I just retested, it is fixed in the latest version on MSYS2. + diff --git a/results/classifier/zero-shot/108/none/1530246 b/results/classifier/zero-shot/108/none/1530246 new file mode 100644 index 000000000..4b7b7ca88 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1530246 @@ -0,0 +1,44 @@ +device: 0.538 +network: 0.422 +socket: 0.421 +KVM: 0.409 +graphic: 0.374 +PID: 0.330 +vnc: 0.281 +semantic: 0.265 +permissions: 0.234 +files: 0.215 +boot: 0.208 +performance: 0.169 +other: 0.166 +debug: 0.131 + +Suppressing kvm rdmsr errors to console + +I am seeing numerous kvm rdmsr messages logged to /dev/tty1 (console), and would like to know how to suppress these messages. I've attempted "echo 1 > /sys/module/kvm/parameters/ignore_msrs" and the messages still appear on tty1. + +I'm seeing the following rdmsr messages: +kvm [22212]: vcpu0 ignored rdmsr: 0x606 +kvm [22212]: vcpu0 ignored rdmsr: 0x611 +kvm [22212]: vcpu0 ignored rdmsr: 0x639 +kvm [22212]: vcpu0 ignored rdmsr: 0x641 +kvm [22212]: vcpu0 ignored rdmsr: 0x619 +kvm [22212]: vcpu0 ignored rdmsr: 0x1ad + + +The following QEMU/KVM RPMs are installed: +ipxe-roms-qemu-20130517-7.gitc4bce43.el7.noarch +libvirt-daemon-driver-qemu-1.2.17-13.el7_2.2.x86_64 +libvirt-daemon-kvm-1.2.17-13.el7_2.2.x86_64 +qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64 +qemu-kvm-common-ev-2.3.0-31.el7_2.4.1.x86_64 +qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64 +qemu-kvm-tools-ev-2.3.0-31.el7_2.4.1.x86_64 + +uname -a +Linux server 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux + +I think this has been likely fixed by the following commit here: +https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=fab0aa3b776f0a3af1db1f5 +... which is part of upstream kernel v4.15. + diff --git a/results/classifier/zero-shot/108/none/1533 b/results/classifier/zero-shot/108/none/1533 new file mode 100644 index 000000000..0f8ba025e --- /dev/null +++ b/results/classifier/zero-shot/108/none/1533 @@ -0,0 +1,16 @@ +device: 0.559 +other: 0.474 +semantic: 0.455 +permissions: 0.373 +performance: 0.360 +graphic: 0.357 +network: 0.331 +boot: 0.166 +debug: 0.126 +socket: 0.073 +files: 0.064 +PID: 0.060 +vnc: 0.056 +KVM: 0.025 + +qemu-i386 should not enable feature LM with named CPU models. diff --git a/results/classifier/zero-shot/108/none/1550743 b/results/classifier/zero-shot/108/none/1550743 new file mode 100644 index 000000000..5dd57e065 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1550743 @@ -0,0 +1,45 @@ +graphic: 0.557 +semantic: 0.402 +other: 0.382 +device: 0.369 +performance: 0.362 +permissions: 0.289 +PID: 0.275 +network: 0.271 +socket: 0.176 +files: 0.171 +debug: 0.155 +boot: 0.113 +vnc: 0.108 +KVM: 0.037 + +connect low speed host devices to qemu ehci does not work + +$ qemu-system-i386 -hda my_x86.img -device ich9-usb-ehci1,id=ehci -device usb-host,vendorid=0x045e,productid=0x071d -serial stdio +qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed) +qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed) +qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed) + +Which is obviously wrong. The ehci specification states: + +Low-speed device, release ownership of port <= Table 2-16. + +Table 2-6: + +Number of Companion Controller (N_CC). This field indicates the number of +companion controllers associated with this USB 2.0 host controller. +A zero in this field indicates there are no companion host controllers. Port-ownership +hand-off is not supported. Only high-speed devices are supported on the host controller +root ports. +A value larger than zero in this field indicates there are companion USB 1.1 host +controller(s). Port-ownership hand-offs are supported. High, Full- and Low-speed +devices are supported on the host controller root ports. + +Which is not longer true, as for example skylake and baytrail offers a dual usb stack of ehci and xhci. In that case, EHCI handles the low speed device as well. + +brgds, +Bert + +Are you sure that EHCI handles low-speed devices in that case? I thought that XHCI is capable of handling low-speed devices instead... +Anyway, QEMU certainly only emulates the EHCI in a traditional way, so if you want to use low-speed devices here, you also have to specify an UHCI controller for them. I.e. as far as I can see, this is not a bug in QEMU, but just a configuration issue. + diff --git a/results/classifier/zero-shot/108/none/1552549 b/results/classifier/zero-shot/108/none/1552549 new file mode 100644 index 000000000..199270f52 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1552549 @@ -0,0 +1,26 @@ +device: 0.486 +debug: 0.400 +graphic: 0.358 +network: 0.333 +boot: 0.313 +performance: 0.309 +other: 0.244 +semantic: 0.229 +socket: 0.217 +files: 0.208 +vnc: 0.184 +permissions: 0.144 +PID: 0.071 +KVM: 0.060 + +qemu-system-i386 verison 2.5.50 fails at lmsw instruction + +I cloned qemu source code from github.com, and compiled it on my Kubuntu 15.10 laptop to run my little OS. When booting my little OS, the virtual machine's screen keep blinking, I guess it's the virtual machine rebooting on and on automatically for some unknown reason, but there is no further information shown on Kubuntu's terminal. I'm pretty sure this problem is not caused by my little OS, because it works just fine in qemu-system-i386 version 2.5.0. + +I debugged my OS and find this problem happens when executing instruction "lmsw ax". Is this a bug, can anyone help me out? + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? If not, can you provide an example for testing? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1563887 b/results/classifier/zero-shot/108/none/1563887 new file mode 100644 index 000000000..c3f1a19e1 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1563887 @@ -0,0 +1,914 @@ +permissions: 0.493 +graphic: 0.473 +device: 0.472 +other: 0.469 +debug: 0.447 +PID: 0.443 +semantic: 0.396 +boot: 0.370 +KVM: 0.334 +files: 0.318 +vnc: 0.285 +performance: 0.267 +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/zero-shot/108/none/1567254 b/results/classifier/zero-shot/108/none/1567254 new file mode 100644 index 000000000..3010a359c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1567254 @@ -0,0 +1,55 @@ +device: 0.401 +graphic: 0.355 +semantic: 0.349 +performance: 0.332 +files: 0.312 +other: 0.303 +PID: 0.302 +permissions: 0.292 +socket: 0.183 +boot: 0.157 +debug: 0.154 +network: 0.136 +vnc: 0.066 +KVM: 0.032 + +qemu-2.5.1 will not run with gtk3/vte + +Using qemu-2.5.1 and compiling without gtk3 and vte-2.90. + +This works: + +CC="gcc -mtune=generic -Os -pipe" CXX="g++ -mtune=generic -Os -pipe -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local --localstatedir=/var --libexecdir=/usr/local/lib/qemu --interp-prefix=/usr/local/share/qemu --audio-drv-list="oss alsa sdl" --target-list="i386-softmmu i386-linux-user x86_64-softmmu x86_64-linux-user" --smbd=/usr/local/sbin/smbd --disable-curses + +find . -name config-host.mak -type f -exec sed -i 's/-O2//g' {} \; + +make +sudo make install + +If I then add gtk3 and vte-2.90 development files and compile again, this fails with or without --disable-docs: + + sudo make install +... +make -C po install +make[1]: Entering directory '/usr/src/qemu-2.5.1/po' + GEN tr.mo +/bin/sh: msgfmt: not found +Makefile:13: recipe for target 'tr.mo' failed +make[1]: *** [tr.mo] Error 127 +make[1]: Leaving directory '/usr/src/qemu-2.5.1/po' +Makefile:443: recipe for target 'install' failed +make: *** [install] Error 2 + +If I then add gettext and re-compile, "qemu-system-x86_64 -blah-blah" opens a window, displays the bios message and stops. + +* configure script should check for gettext +* if "--disable-docs" is passed, "make install" should not try to install docs +* qemu should work when compiled with gtk3 and vte +* why does qemu insist on vte-2.90, when vte-2.91 has been out +/- 2 years? + +Looking through old bug tickets... can you still reproduce these issues with the latest version of QEMU? + +Things seem to work with gtk3 and qemu-3.1.0 - I didn't try vte though... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1568356 b/results/classifier/zero-shot/108/none/1568356 new file mode 100644 index 000000000..b26a931cb --- /dev/null +++ b/results/classifier/zero-shot/108/none/1568356 @@ -0,0 +1,86 @@ +PID: 0.411 +device: 0.378 +debug: 0.372 +performance: 0.357 +graphic: 0.340 +other: 0.339 +permissions: 0.339 +network: 0.329 +socket: 0.319 +semantic: 0.307 +files: 0.306 +boot: 0.205 +vnc: 0.200 +KVM: 0.156 + +ERROR:ui/sdl2-2d.c:120:sdl2_2d_switch: + +when display sdl is selected in display switch resolution qemu exit with a core dump with this message + + +ERROR:ui/sdl2-2d.c:120:sdl2_2d_switch: code should not be reached + +My Machine is a Cyrus+ PowerPc P5020 4gb ram Radeon 6570 2Gb + +This issue affected PowerMac G5 quad too . + +My distro is Mate 16.04 + +Could you add a debug printf before that assert statement in the code to see which format is missing here? So that the default case looks like: + + default: + printf("Surface format is: %x\n", surface_format(scon->surface)); + g_assert_not_reached(); + + +Hi T. +i had been add the code line but cc exit with error and dont buil + +CC ui/console-gl.o +ui/console-gl.c: In function ‘surface_gl_create_texture’: +ui/console-gl.c:96:52: error: ‘scon’ undeclared (first use in this function) + printf("Surface format is: %x\n", surface_format(scon->surface)); + ^ +ui/console-gl.c:96:52: note: each undeclared identifier is reported only once for each function it appears in +/home/amigaone/src/qemu/rules.mak:57: recipe for target 'ui/console-gl.o' failed +make: *** [ui/console-gl.o] Error 1 +make: *** Waiting for unfinished jobs.... + + +You've apparently added it to console-gl.c ... your original description was about sdl2-2d.c, so please add the code there. In console-gl.c, you could use this statement instead: + + printf("gl Surface format is: %x\n", surface->format); + +I just noticed that somebody submitted a related patch recently: + +https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg02702.html + +Could you please check whether this fixes your issue here with sdl2-2d.c, too? + +Hi T. +I been installed the patch . +note im testing the fedora 24 and the last mate 16.10 +on fedora 24 qemu 2.6 all build ok but when i run the qemu i have an illegal istruction and the crash of qemu... dont worry about im sure is not a qemu issue but some unstable library on fedora because this is effecting all sdl software. + +On mate 16.10 qemu 2.6 is not building at all i had been reported the issue about . +I cant say if the patch is working or not since the two distro will be more stable. + +i will check later if the oldest qemu 2.5.x with the applied patch will build on mate 16 and hope gave a positive feedback. + +Luigi + +Hi T, +i can confirm the patch is working . sdl2 switch screen is fixed . +i had been tested it on 2.5.1 and is ok. +I think will be better add this in the qemu git + +next step sdl gl ;-) +Many thanks +Luigi + +Looking at the changelog, the patch has been pull in yesterday: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=435deffefbb07d9a0cafef4 +So marking this bug as fixed. + +Commit 435deffefbb07d9a0cafef4 has been released with QEMU v2.7.0 already + diff --git a/results/classifier/zero-shot/108/none/1575 b/results/classifier/zero-shot/108/none/1575 new file mode 100644 index 000000000..91b813b3b --- /dev/null +++ b/results/classifier/zero-shot/108/none/1575 @@ -0,0 +1,16 @@ +other: 0.511 +device: 0.441 +performance: 0.382 +graphic: 0.215 +boot: 0.157 +KVM: 0.143 +debug: 0.138 +vnc: 0.131 +network: 0.113 +PID: 0.082 +semantic: 0.071 +socket: 0.034 +permissions: 0.013 +files: 0.001 + +how to implement a heterogeneous machine(several sysbus/mem map)? diff --git a/results/classifier/zero-shot/108/none/1576347 b/results/classifier/zero-shot/108/none/1576347 new file mode 100644 index 000000000..10736c422 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1576347 @@ -0,0 +1,305 @@ +KVM: 0.302 +other: 0.293 +vnc: 0.238 +device: 0.228 +debug: 0.221 +permissions: 0.212 +files: 0.212 +network: 0.199 +boot: 0.185 +performance: 0.180 +semantic: 0.162 +graphic: 0.160 +PID: 0.146 +socket: 0.145 + +Only one NVMe device is usable in Windows (10) guest + +Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +QEMU version: 2.5.0 + +Kernel: 4.5.1 (Arch Linux) + +When there are two NVMe devices specified, only the second one will be usable in Windows. The following error is shown under "Device status" of the failed NVMe controller in Device Manager: + +"This device cannot start. (Code 10) + +The I/O device is configured incorrectly or the configuration parameters to the driver are incorrect." + +The only thing seems suspicious to me is that the nvme emulation in qemu does not have WWN/EUI-64 set for the devices, though I have no idea at all whether that is mandatory: + +"C:\Windows\system32>sg_vpd -i PD1 +Device Identification VPD page: + Addressed logical unit: + designator type: SCSI name string, code set: UTF-8 + SCSI name string: + 8086QEMU NVMe Ctrl 00012BDAC262CF831698 + +C:\Windows\system32>sg_vpd -p sn PD1 +Unit serial number VPD page: + Unit serial number: 0000_0000_0000_0000." + + + +You can see from the "SCSI name string" that the working NVMe device is the second one specified in the command. + + + + + +"if=virtio" (which similarly has one controller per drive and has each controller occupies a pci slot as the nvme emulation) works fine: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive file=disks/one.img,if=virtio,format=qcow2,id=one -drive file=disks/two.img,if=virtio,format=qcow2,id=two + +Apparently it works fine in Linux though: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=Downloads/archlinux-2016.04.01-dual.iso,media=cdrom -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +I also tested WIndows installation ISOs instead as well. + +Windows 10 Enterprise 10586: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=Downloads/10586.0.151029-1700.TH2_RELEASE_CLIENTENTERPRISEEVAL_OEMRET_X64FRE_EN-US.ISO,media=cdrom -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +Windows Server 2016 Technical Preview 5: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=Downloads/14300.1000.160324-1723.RS1_RELEASE_SVC_SERVER_OEMRET_X64FRE_EN-US.ISO,media=cdrom -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +Both of them shows only one of the NVMe drives. + +I also tested with two versions of OVMF, which are "18419" (https://github.com/tianocore/edk2/commit/ddd097e33f6e6829dc0413820e9971f3bf025f87) and "18455" (https://github.com/tianocore/edk2/commit/59844e126614fc8275aab083fafa5818cde0901c). + +On Thu, Apr 28, 2016 at 05:44:21PM -0000, Tom Yan wrote: + +CCing Keith Busch <email address hidden>, maintainer of QEMU NVMe. +Maybe he has an idea. + +> Public bug reported: +> +> Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m +> 4G -net bridge -net nic -full-screen -drive +> file=ovmf_x64.bin,format=raw,if=pflash -drive +> file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive +> file=disks/one.img,if=none,format=qcow2,id=one -drive +> file=disks/two.img,if=none,format=qcow2,id=two -device +> nvme,drive=one,serial=E86C3CFC43518D6F -device +> nvme,drive=two,serial=2BDAC262CF831698 +> +> QEMU version: 2.5.0 +> +> Kernel: 4.5.1 (Arch Linux) +> +> When there are two NVMe devices specified, only the second one will be +> usable in Windows. The following error is shown under "Device status" of +> the failed NVMe controller in Device Manager: +> +> "This device cannot start. (Code 10) +> +> The I/O device is configured incorrectly or the configuration parameters +> to the driver are incorrect." +> +> The only thing seems suspicious to me is that the nvme emulation in qemu +> does not have WWN/EUI-64 set for the devices, though I have no idea at +> all whether that is mandatory: +> +> "C:\Windows\system32>sg_vpd -i PD1 +> Device Identification VPD page: +> Addressed logical unit: +> designator type: SCSI name string, code set: UTF-8 +> SCSI name string: +> 8086QEMU NVMe Ctrl 00012BDAC262CF831698 +> +> C:\Windows\system32>sg_vpd -p sn PD1 +> Unit serial number VPD page: +> Unit serial number: 0000_0000_0000_0000." +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Attachment added: "Screenshot of Device Manager and the error." +> https://bugs.launchpad.net/bugs/1576347/+attachment/4650548/+files/01.PNG +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1576347 +> +> Title: +> Only one NVMe device is usable in Windows (10) guest +> +> Status in QEMU: +> New +> +> Bug description: +> Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m +> 4G -net bridge -net nic -full-screen -drive +> file=ovmf_x64.bin,format=raw,if=pflash -drive +> file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive +> file=disks/one.img,if=none,format=qcow2,id=one -drive +> file=disks/two.img,if=none,format=qcow2,id=two -device +> nvme,drive=one,serial=E86C3CFC43518D6F -device +> nvme,drive=two,serial=2BDAC262CF831698 +> +> QEMU version: 2.5.0 +> +> Kernel: 4.5.1 (Arch Linux) +> +> When there are two NVMe devices specified, only the second one will be +> usable in Windows. The following error is shown under "Device status" +> of the failed NVMe controller in Device Manager: +> +> "This device cannot start. (Code 10) +> +> The I/O device is configured incorrectly or the configuration +> parameters to the driver are incorrect." +> +> The only thing seems suspicious to me is that the nvme emulation in +> qemu does not have WWN/EUI-64 set for the devices, though I have no +> idea at all whether that is mandatory: +> +> "C:\Windows\system32>sg_vpd -i PD1 +> Device Identification VPD page: +> Addressed logical unit: +> designator type: SCSI name string, code set: UTF-8 +> SCSI name string: +> 8086QEMU NVMe Ctrl 00012BDAC262CF831698 +> +> C:\Windows\system32>sg_vpd -p sn PD1 +> Unit serial number VPD page: +> Unit serial number: 0000_0000_0000_0000." +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1576347/+subscriptions +> + + +On Fri, Apr 29, 2016 at 10:10:39AM +0100, Stefan Hajnoczi wrote: +> On Thu, Apr 28, 2016 at 05:44:21PM -0000, Tom Yan wrote: +> +> CCing Keith Busch <email address hidden>, maintainer of QEMU NVMe. +> Maybe he has an idea. + +Thanks for the report. Sounds like a Windows specific issue as I have no +problem with multiple nvme drives on my dev machines: + +[Host] +# uname -r +4.6.0-rc5+ + +# qemu-system-x86_64 --version +QEMU emulator version 2.5.50, Copyright (c) 2003-2008 Fabrice Bellard + +# qemu-system-x86_64 -m 4096 -smp 4 -enable-kvm debian.img \ + -drive file=nvme.1.img,if=none,id=one -device nvme,drive=one,serial=foo \ + -drive file=nvme.2.img,if=none,id=two -device nvme,drive=two,serial=bar + +[Guest] +# uname -r +4.5.0 + +# ls /dev/nvme* +/dev/nvme0 /dev/nvme0n1 /dev/nvme1 /dev/nvme1n1 + +# nvme id-ctrl /dev/nvme0 | grep sn +sn : foo + +# nvme id-ctrl /dev/nvme1 | grep sn +sn : bar + +> > When there are two NVMe devices specified, only the second one will be +> > usable in Windows. The following error is shown under "Device status" of +> > the failed NVMe controller in Device Manager: +> > +> > "This device cannot start. (Code 10) +> > +> > The I/O device is configured incorrectly or the configuration parameters +> > to the driver are incorrect." +> > +> > The only thing seems suspicious to me is that the nvme emulation in qemu +> > does not have WWN/EUI-64 set for the devices, though I have no idea at +> > all whether that is mandatory: + +These are not mandatory. They were only introduced in the 1.1 and 1.2 versions +of the NVMe spec, though we only cared to emulate the 1.0 portions rather than +provide a full featured NVMe controller. + +That said, there needs to be care in the host OS to provide an appropriate +translation IF it is using a SCSI stack to talk to NVMe. Linux doesn't care, +but Windows does. + +> > "C:\Windows\system32>sg_vpd -i PD1 +> > Device Identification VPD page: +> > Addressed logical unit: +> > designator type: SCSI name string, code set: UTF-8 +> > SCSI name string: +> > 8086QEMU NVMe Ctrl 00012BDAC262CF831698 + +The above looks reasonable for your second controller that had serial +2BDAC262CF831698. + +> > C:\Windows\system32>sg_vpd -p sn PD1 +> > Unit serial number VPD page: +> > Unit serial number: 0000_0000_0000_0000." + +This doesn't look like a very good SCSI-NVMe translation and possibly +suspicious. But I don't know the first thing about windows; does it care about +unique unit serial numbers in order to surface a "SCSI" disk? + + +> > C:\Windows\system32>sg_vpd -p sn PD1 +> > Unit serial number VPD page: +> > Unit serial number: 0000_0000_0000_0000." + +I checked your serial number against the SNT refernce on nvmexpress.org and +it's definitely the wrong translation, so that has to be a guest OS driver bug +(Linux has the right translation if interested, but it's use is deprecated). + +I pinged some Windows comrades to see if a potential serial conflict prevents +both disks from surfacing. + +I'm surprised to see this bad translation as I know of folks successfully +testing multiple nvme drives in various versions of Windows with both the OFA +and Microsoft drivers. An emulated NVMe is no different than real h/w for +namespace identification from the host's perspective. + + +The problem still exists with qemu 2.7.0 and Windows 10 RS1. Btw I just did one more test, that I disable the working nvme controller in Device Manager to see if it makes the non-working one comes alive, but it does not, even if I reboot the virtual machine. + +For the record, the serial number translation is not fixed in RS1 either. + +Trying it on Windows 10 guest and QEMU 2.8.0 has the same issue. However, I noticed that: + Supplying 1 NVMe drive -> Win10 sees it. + Supplying 2 NVMe drives -> Win10 sees only one of them. + Supplying 3 NVMe drives -> Win10 sees only two of them. +So I still have been able to create a ReFS mirrored storage space with two NVMe disks under QEMU, I just had to pass three drives instead of two: + +qemu-system-x86_64 -enable-kvm <...> -drive file=/media/ssd/NVMe_drvA.qcow2,id=diskNVMeA,format=qcow2,if=none -drive file=/media/ssd/NVMe_drvB.qcow2,id=diskNVMeB,format=qcow2,if=none -drive file=/media/ssd/NVMe_drvC.qcow2,id=diskNVMeC,format=qcow2,if=none -device nvme,drive=diskNVMeA,serial=foo -device nvme,drive=diskNVMeB,serial=foo -device nvme,drive=diskNVMeC,serial=foo + +Hope this helps, +--Sergey + +Hello, I can also confirm that if you have a series of NVMe devices, at first when just the OVMF boot menu has loaded, using qemu with a -monitor and typing 'info pci', it appears that all are given valid bus addresses. + +However, once the Windows 10 x64 installer iso loads, it seems that every other NVMe device stays initialized correctly, but the ones in-between switch to a 0xfffff... bus address. So, for example, with 6 devices, numbers 1,3,5 will get initialized and recognized by the Windows installer, and 2,4,6 will not. Not sure if this clue helps identify this a qemu or Windows issue or not, but I thought it was worth noting. + +Also, I found that an alternative way to getting two or more NVMe devices successfully recognized by Windows is to use multiple root PCIe devices like so: + +qemu-system-x86_64 \ +-enable-kvm \ +-machine pc-q35-2.11,accel=kvm \ +-nodefaults \ +... +-device pcie-root-port,id=pcie_r0,bus=pcie.0,chassis=0,slot=0 \ +-device nvme,drive=disk0,serial=serial0,bus=pcie_r0 \ +-drive id=disk0,if=none,media=disk,cache=none,aio=native,format=raw,discard=unmap,file=/opt/os.raw \ +-device pcie-root-port,id=pcie_r1,bus=pcie.0,chassis=0,slot=1 \ +-device nvme,drive=disk1,serial=serial1,bus=pcie_r1 \ +-drive id=disk1,if=none,media=disk,cache=none,aio=native,format=raw,discard=unmap,file=/opt/data.raw \ + +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/zero-shot/108/none/1580 b/results/classifier/zero-shot/108/none/1580 new file mode 100644 index 000000000..ea2cb4003 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1580 @@ -0,0 +1,59 @@ +vnc: 0.428 +permissions: 0.403 +PID: 0.337 +other: 0.301 +device: 0.280 +KVM: 0.253 +performance: 0.251 +debug: 0.218 +network: 0.216 +semantic: 0.214 +files: 0.211 +boot: 0.210 +graphic: 0.208 +socket: 0.183 + +QEMU crashes when running inside Hyper-V VM on AMD EPYC +Description of problem: +Starting the VM very rarely succeeds and often it crashes with: +``` +# qemu-system-x86_64 -cpu EPYC -machine accel=kvm -smp 1 -m 512 -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=OVMF_VARS.fd -drive file=debian-11-nocloud-amd64-20230124-1270.qcow2,format=qcow2 -snapshot -monitor none +qemu: module ui-ui-gtk not found, do you want to install qemu-system-gui package? +qemu: module ui-ui-sdl not found, do you want to install qemu-system-gui package? +VNC server running on ::1:5900 +KVM internal error. Suberror: 1 +extra data[0]: 0x0000000000000001 +extra data[1]: 0x96d0cff2bed0cf0f +extra data[2]: 0x0bfd29af72b35c7c +extra data[3]: 0x0000000000000400 +extra data[4]: 0x0000000100000004 +extra data[5]: 0x00000000581c356c +extra data[6]: 0x0000000000000000 +extra data[7]: 0x0000000000000000 +emulation failure +EAX=fffd26a4 EBX=00000000 ECX=00000000 EDX=b731cdad +ESI=00000101 EDI=00005042 EBP=fffcc000 ESP=581c3564 +EIP=fffff8a8 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0010 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] +SS =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= fffffee0 00000027 +IDT= 00000000 00000000 +CR0=40000033 CR2=00000000 CR3=00800000 CR4=00000660 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000100 +Code=00 0f 20 e0 0f ba e8 05 0f 22 e0 31 db e9 13 02 00 00 85 c0 <75> 38 b9 80 00 00 c0 0f 32 0f ba e8 08 0f 30 31 db b9 01 00 00 00 0f a3 0d 04 b0 80 00 74 +``` +Steps to reproduce: +1. Create a [Standard_D8ads_v5 VM](https://learn.microsoft.com/en-us/azure/virtual-machines/dasv5-dadsv5-series) (AMD EPYC 7763 64-Core Processor) in Azure with Debian 11 +2. Install `qemu-system-x86` (1:7.2+dfsg-5~bpo11+1) from `bullseye-backports` +3. Install `ovmf` (2022.11-6) from `bookworm` (testing) +4. Run the commands under "QEMU command line" +Additional information: +VNC displays "Guest has not initialized the display (yet)". The setup works perfectly on a [Standard_D8ds_v5 VM](https://learn.microsoft.com/en-us/azure/virtual-machines/ddv5-ddsv5-series) (Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz). diff --git a/results/classifier/zero-shot/108/none/1586 b/results/classifier/zero-shot/108/none/1586 new file mode 100644 index 000000000..da1dfdccd --- /dev/null +++ b/results/classifier/zero-shot/108/none/1586 @@ -0,0 +1,122 @@ +graphic: 0.215 +vnc: 0.212 +PID: 0.189 +device: 0.184 +permissions: 0.170 +files: 0.163 +KVM: 0.151 +other: 0.135 +boot: 0.129 +socket: 0.129 +semantic: 0.126 +performance: 0.123 +debug: 0.107 +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/zero-shot/108/none/159 b/results/classifier/zero-shot/108/none/159 new file mode 100644 index 000000000..f6816a55c --- /dev/null +++ b/results/classifier/zero-shot/108/none/159 @@ -0,0 +1,16 @@ +graphic: 0.546 +device: 0.500 +performance: 0.496 +semantic: 0.409 +permissions: 0.258 +network: 0.158 +other: 0.128 +debug: 0.126 +files: 0.084 +socket: 0.062 +vnc: 0.060 +boot: 0.047 +KVM: 0.029 +PID: 0.018 + +qemu-nbd -l and -s options don't work together diff --git a/results/classifier/zero-shot/108/none/1590 b/results/classifier/zero-shot/108/none/1590 new file mode 100644 index 000000000..6801e5353 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1590 @@ -0,0 +1,136 @@ +other: 0.565 +graphic: 0.477 +permissions: 0.468 +device: 0.466 +debug: 0.448 +performance: 0.373 +PID: 0.365 +semantic: 0.353 +files: 0.322 +KVM: 0.311 +network: 0.308 +boot: 0.307 +vnc: 0.269 +socket: 0.233 + +Regression: ARMv8M secure mode debugging non-functional since ~v7.2.0 +Description of problem: +Prior to qemu commit 4a35855682cebb89f9630b07aa9fd37c4e8c733b, both semihosting printf calls and debugging via gdb work as expected. + +Builds of qemu containing commit 4a35855682cebb89f9630b07aa9fd37c4e8c733b do not produce any semihosting output and are not debuggable via gdb. +Steps to reproduce: +1. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf`` with qemu v7.1.0, note the "blinking" print to the console once a second. +2. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf`` with qemu v7.2.0, note that no messages are printed to the console. +3. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf -S -s`` and attach gdb with the following gdbinit file. +Additional information: +Log of successful gdb session with the attached patch on top of qemu master branch: +``` +% arm-none-eabi-gdb build/mps2_an505_cm33_blink_demo.elf +GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "--host=x86_64-apple-darwin19.6.0 --target=arm-none-eabi". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.linaro.org/>. +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/mps2_an505_cm33_blink_demo.elf... +The target architecture is set to "armv8-m.main". +Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:172 +172 { +Section .privileged_functions, range 0x10000000 -- 0x10008000: matched. +Section .text, range 0x10008000 -- 0x10019c18: matched. +Section .rodata, range 0x10019c18 -- 0x1001b270: matched. +Section .ARM.exidx, range 0x1001b270 -- 0x1001b278: matched. +Section .copy.table, range 0x1001b278 -- 0x1001b284: matched. +Section .data, range 0x1001b28c -- 0x1001bb90: matched. +Section .ram_vectors, range 0x1001bb90 -- 0x1001bdd0: matched. +Section .zero.table, range 0x1001b284 -- 0x1001b28c: matched. +Breakpoint 1 at 0x10009900: file /FreeRTOS/Demo/ARM_MPS/fault_handlers.c, line 494. +(gdb) s +174 asm volatile +(gdb) s +189 init_data_sections(); +(gdb) s +init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:99 +99 for( pCopyTable = &__copy_table_start__; pCopyTable <= &__copy_table_end__; pCopyTable++ ) +(gdb) s +101 for( dataIndex = 0; dataIndex < pCopyTable->uxLen; dataIndex++ ) +(gdb) info locals +pCopyTable = 0x1001b278 +dataIndex = 0 +(gdb) print /x *0xE000ED08 +$1 = 0x10000000 +``` + +Log of an unsuccessful gdb session with qemu v7.2.0 +``` +pbartell@147dda7342a9 ARM_MPS % arm-none-eabi-gdb build/mps2_an505_cm33_blink_demo.elf +GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "--host=x86_64-apple-darwin19.6.0 --target=arm-none-eabi". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.linaro.org/>. +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/mps2_an505_cm33_blink_demo.elf... +The target architecture is set to "armv8-m.main". +Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:172 +172 { +Section .privileged_functions, range 0x10000000 -- 0x10008000: MIS-MATCHED! +Section .text, range 0x10008000 -- 0x10019c18: MIS-MATCHED! +Section .rodata, range 0x10019c18 -- 0x1001b270: MIS-MATCHED! +Section .ARM.exidx, range 0x1001b270 -- 0x1001b278: MIS-MATCHED! +Section .copy.table, range 0x1001b278 -- 0x1001b284: MIS-MATCHED! +Section .data, range 0x1001b28c -- 0x1001bb90: MIS-MATCHED! +Section .ram_vectors, range 0x1001bb90 -- 0x1001bdd0: MIS-MATCHED! +Section .zero.table, range 0x1001b284 -- 0x1001b28c: MIS-MATCHED! +warning: One or more sections of the target image does not match +the loaded file + +Breakpoint 1 at 0x10009900: file /FreeRTOS/FreeRTOS/Demo/ARM_MPS/fault_handlers.c, line 494. +(gdb) s +Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:174 +174 asm volatile +(gdb) s +Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:189 +189 init_data_sections(); +(gdb) s +init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:95 +95 { +(gdb) s +init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:99 +99 for( pCopyTable = &__copy_table_start__; pCopyTable <= &__copy_table_end__; pCopyTable++ ) +(gdb) info locals +pCopyTable = <error reading variable pCopyTable (Cannot access memory at address 0x381fffdc)> +dataIndex = <error reading variable dataIndex (Cannot access memory at address 0x381fffd8)> +(gdb) print /x *0xE000ED08 +$1 = 0x0 +(gdb) quit +``` + +.gdbinit file: +``` +set architecture armv8-m.main +target extended-remote :1234 +compare-sections +break HardFault_Handler +``` + +[mps2_an505_cm33_blink_demo.elf](/uploads/c86e086b00651a8d5392857b9e4a2c4d/mps2_an505_cm33_blink_demo.elf) +[target-arm-Fix-debugging-of-ARMv8M-Secure-code.patch](/uploads/5735d5f7d7b15dbbeb0c2d214a46c1a8/target-arm-Fix-debugging-of-ARMv8M-Secure-code.patch) diff --git a/results/classifier/zero-shot/108/none/1593605 b/results/classifier/zero-shot/108/none/1593605 new file mode 100644 index 000000000..efb4ab08a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1593605 @@ -0,0 +1,262 @@ +permissions: 0.428 +KVM: 0.400 +other: 0.400 +vnc: 0.388 +boot: 0.333 +device: 0.331 +network: 0.329 +semantic: 0.313 +files: 0.308 +socket: 0.300 +debug: 0.299 +performance: 0.298 +graphic: 0.296 +PID: 0.274 + +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/zero-shot/108/none/1596204 b/results/classifier/zero-shot/108/none/1596204 new file mode 100644 index 000000000..8e817c857 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1596204 @@ -0,0 +1,41 @@ +device: 0.551 +other: 0.531 +performance: 0.522 +graphic: 0.321 +semantic: 0.304 +debug: 0.303 +permissions: 0.293 +network: 0.270 +PID: 0.235 +boot: 0.163 +socket: 0.161 +vnc: 0.134 +files: 0.048 +KVM: 0.016 + +UART problem in raspi2 + +I was trying to run the raspberry pi uart example at https://github.com/dwelch67/raspberrypi/tree/master/uart01 using qemu 2.6.0, but it didn't work. + +The steps I took were: +* Edit uart01/memmap and change origin to 0x10000 (which is the address qemu starts executing), +* make +* /usr/local/bin/qemu-system-arm -machine raspi2 -m 512M -nographic -gdb tcp::26000 -S -kernel uart01.bin + +Then start arm-none-eabi-gdb and run following commands: + +target remote localhost:26000 +symbol-file ./uart01.elf + + +Then, when I start the program, it seems that the GET32(AUX_MU_LSR_REG)&0x20 condition never becomes true. + +This works on actual hardware, so I am wondering if I'm doing any steps incorrectly or missing. + +This is because you're running a binary for the raspberry pi 1 on a model of the raspberry pi 2. The peripherals are at different locations on the two boards, and so your program doesn't work. You can fix that by changing all the register addresses that start 0x20..... to 0x3f...., or more complicatedly by using the boards/cpuid/ code in that raspberrypi repo to detect the correct PBASE value to use. + +Secondly, the output goes to the second serial port, which in your command line is not being directed anywhere. You can put the second serial port's output on stdio with the first serial port output thrown away using '-serial null -serial stdio'. (For more complicated redirections, see the QEMU docs.) + +If I do those two things, then the uart01 example runs fine on QEMU. + + diff --git a/results/classifier/zero-shot/108/none/160 b/results/classifier/zero-shot/108/none/160 new file mode 100644 index 000000000..c054fc4a8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/160 @@ -0,0 +1,16 @@ +other: 0.341 +device: 0.203 +graphic: 0.156 +semantic: 0.107 +performance: 0.036 +boot: 0.033 +vnc: 0.020 +KVM: 0.010 +debug: 0.009 +permissions: 0.007 +PID: 0.005 +network: 0.005 +files: 0.001 +socket: 0.001 + +Record/replay example does not work diff --git a/results/classifier/zero-shot/108/none/1600 b/results/classifier/zero-shot/108/none/1600 new file mode 100644 index 000000000..812ff4306 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1600 @@ -0,0 +1,40 @@ +debug: 0.054 +graphic: 0.037 +PID: 0.033 +permissions: 0.026 +semantic: 0.024 +vnc: 0.022 +other: 0.020 +device: 0.015 +boot: 0.014 +files: 0.014 +network: 0.013 +performance: 0.013 +socket: 0.012 +KVM: 0.012 + +Aarch64/FEAT_SEL2 secure S1 translation for a NS page resolves to the secure IPA space +Description of problem: +Follow up to https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmware.org/thread/ZUHRGWVDPUQ5CK6SRWZ7AMI5IKVS6J47/ + +In context of Hafnium project (SEL2 / SPM firmware), implementing secure/non-secure page tables split rooted by VTTBR/VSTTBR in TZ secure world. +Observing transactions always resolve to the secure IPA space (hence to the page tables rooted to by VSTTBR) whichever the state of the S1 MMU translation NS bit. +Access to a page mapped NS from the SEL1 Trusted OS, causes a S2 page fault even though mapped in page tables rooted to by VTTBR. + +The VTCR_EL2/VSTCR_EL2 settings at SEL2 are as follows: +VTCR_EL2.NSA/NSW=10b +VSTCR_EL2.SA/SW=00b + +Note the same set of changes (https://review.trustedfirmware.org/q/topic:%2522od/split-vttbr%2522+status:open) run fine for the same scenario on FVP. +Steps to reproduce: +1. build qemu master 60ca584b8af0de525656f959991a440f8c191f12 +2. unzip [qemu-sel2-vttbr-fail.zip](/uploads/ec556347c32d97f79c140c5bccf45c6b/qemu-sel2-vttbr-fail.zip) +3. Run + +``` +<...>/qemu/build/aarch64-softmmu/qemu-system-aarch64 -nographic -serial file:uart0.log -serial file:uart1.log -smp 2 -machine virt,secure=on,mte=on,gic-version=3,virtualization=true -cpu max,sme=off,pauth-impdef=on -d unimp -semihosting-config enable=on,target=native -m 1057 -bios bl1.bin -initrd rootfs.cpio.gz -kernel Image -no-acpi -append 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2 nokaslr' -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000 -netdev user,id=vmnic -device virtio-net-device,netdev=vmnic +``` +Additional information: +[qemu-60ca58-qemu-tfa-hf-linux-fail.txt](/uploads/1db0155fc49140cf52913cd75b7494c1/qemu-60ca58-qemu-tfa-hf-linux-fail.txt) illustrates the failure, linux boot stops, after sharing a NS page to the TOS, and the TOS retrieving the page, mapping as NS and accessing it (ends in a dead loop, because of the S2 PF in the TOS). + +[qemu-tfa-hf-linux-pass.txt](/uploads/4e672617838e40fe3614c127531443b5/qemu-tfa-hf-linux-pass.txt) shows the expected output where the NS mem sharing operation succeeds. diff --git a/results/classifier/zero-shot/108/none/1605611 b/results/classifier/zero-shot/108/none/1605611 new file mode 100644 index 000000000..acc6b22d0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1605611 @@ -0,0 +1,78 @@ +other: 0.517 +semantic: 0.509 +permissions: 0.399 +PID: 0.389 +performance: 0.380 +device: 0.375 +graphic: 0.349 +debug: 0.338 +vnc: 0.335 +KVM: 0.301 +network: 0.264 +files: 0.256 +boot: 0.247 +socket: 0.215 + +memsave returns invalid addr when trying to read a 64 bits address + +I am trying to read the first 16 bytes of the System Process on a Windows XP x64 SP2 using the memsave monitor command. + +I cloned the latest release of QEMU, v2.6.0, configured it with +./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl +and compiled it. + +I first tried to use memsave against Windows XP SP3 32 bits. +This is the procedure i used : + +1 - start the VM with : +./i386-softmmu/qemu-system-i386 --enable-kvm -monitor stdio -hda ~/vm/winxp.qcow2 +and wait for the desktop +2 - take a physical memory dump with : +pmemsave 0 134217728 dump.raw +3 - call rekall on this memory dump to identify running processes : +rekall -f dump.raw pslist +_EPROCESS Name PID PPID Thds Hnds Sess Wow64 Start Exit +---------- -------------------- ----- ------ ------ -------- ------ ------ ------------------------ ------------------------ +0x80e8fa00 System 4 0 46 148 - False - - +4 - read the first 16 bytes of the System PROCESS struct : +memsave 0x80e8fa00 16 system +5 - check the content with hexdump : +00000000 03 00 1b 00 00 00 00 00 08 fa e8 80 08 fa e8 80 +you can recognize here the beginning of an EPROCESS struct. + +So on a 32 bits Windows XP OS, it works. + +But when i tried on Windows XP SP2 64 bits, rekall gave me the following output : + _EPROCESS Name PID PPID Thds Hnds Sess Wow64 Start Exit +-------------- -------------------- ----- ------ ------ -------- ------ ------ ------------------------ ------------------------ +0xfadffd71d040 System 4 0 51 398 - False - - +And when i tried to read the memory with memsave : +memsave 0xfadffd71d040 16 system + +I had the following error : +Invalid addr 0x0000fadffd71d040/size 16 specified + +This address is supposed to be valid because I am reading the System EProcess struct, which should not be in the paged pool memory I think. +Also i disabled the paging file to be sure and the bug is still present. + +Furthermore the bug is reproducible on the latest QEMU (01a720125f5e2f0a23d2682b39dead2fcc820066). + +Can you confirm that this is a bug ? +Should i check something ? + +Thanks ! + +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/zero-shot/108/none/1606899 b/results/classifier/zero-shot/108/none/1606899 new file mode 100644 index 000000000..20277fc84 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1606899 @@ -0,0 +1,253 @@ +KVM: 0.578 +other: 0.542 +vnc: 0.494 +permissions: 0.434 +device: 0.410 +performance: 0.387 +network: 0.379 +graphic: 0.378 +boot: 0.372 +semantic: 0.357 +debug: 0.351 +socket: 0.348 +PID: 0.334 +files: 0.305 + +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/zero-shot/108/none/1608 b/results/classifier/zero-shot/108/none/1608 new file mode 100644 index 000000000..a2f239ece --- /dev/null +++ b/results/classifier/zero-shot/108/none/1608 @@ -0,0 +1,16 @@ +device: 0.533 +performance: 0.529 +debug: 0.502 +graphic: 0.483 +boot: 0.328 +vnc: 0.291 +other: 0.280 +semantic: 0.212 +socket: 0.193 +KVM: 0.129 +network: 0.114 +permissions: 0.107 +PID: 0.051 +files: 0.008 + +QEMU gives wrong MPIDR value for Arm CPU types with MT=1 diff --git a/results/classifier/zero-shot/108/none/1610368 b/results/classifier/zero-shot/108/none/1610368 new file mode 100644 index 000000000..ced39527b --- /dev/null +++ b/results/classifier/zero-shot/108/none/1610368 @@ -0,0 +1,109 @@ +KVM: 0.461 +vnc: 0.457 +graphic: 0.455 +semantic: 0.451 +other: 0.447 +PID: 0.446 +debug: 0.440 +network: 0.433 +performance: 0.428 +socket: 0.428 +permissions: 0.425 +files: 0.422 +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/zero-shot/108/none/1613 b/results/classifier/zero-shot/108/none/1613 new file mode 100644 index 000000000..12df5d2b8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1613 @@ -0,0 +1,52 @@ +files: 0.558 +graphic: 0.531 +device: 0.492 +performance: 0.468 +socket: 0.377 +network: 0.328 +PID: 0.286 +other: 0.276 +vnc: 0.275 +permissions: 0.239 +semantic: 0.224 +boot: 0.203 +debug: 0.169 +KVM: 0.116 + +Enhanced SuperSpeed Isochronous Endpoints with high-bandwidth pipes not working (Webcams and Microphones) +Description of problem: +I have encountered an issue with QEMU when forwarding HD webcams and microphones in SuperSpeed mode. + +When passing the USB webcam "Logitech BRIO Ultra HD Webcam" to the guest using USB HighSpeed mode, all pixel formats and video modes work as expected. However, when using SuperSpeed mode, only the MJPEG format operates at low resolutions. I have attached a [USB_Webcam_Testing_Truth_Table.pdf](/uploads/309d493989da1164198af0b315012fb1/USB_Webcam_Testing_Truth_Table.pdf) that displays the functioning modes. + +This issue arises with both qemu-xhci and nec-usb-xhci xHCI implementations, as well as with usb-host and usb-redir. + +Upon tracing and comparing the USB packets from the host and guest systems, I discovered an issue with the isochronous endpoint configurations supporting "high bandwidth" pipes (e.g., SS Companion Descriptor with bMaxBurst > 0). I created three pcap files to illustrate the problem: +1. [host-libusb.pcapng](/uploads/18a66948dc6dc10ff68b7f55d70fa209/host-libusb.pcapng) +2. [qemu-guest.pcapng](/uploads/b616507f2f7c1c042a9d085dc3af579f/qemu-guest.pcapng) +3. [host-native.pcapng](/uploads/279aa7f264a75a77203fa7bf6c5afc83/host-native.pcapng) + +To generate each capture, I executed the following command: +```console +timeout --preserve-status 3s ffplay -f v4l2 -i "/dev/video0" -input_format mjpeg -framerate 30 -video_size 1920x1060 +``` + +The "SET INTERFACE" packet reveals that the USB video driver selects bAlternateSetting=7, which has the following parameters: +``` +wMaxPacketSize: 1024 +bMaxBurst: 2 +bmAttributes: 0x01 + .... ..01 = Mult: 1 +``` +According to Section 4.14.2.1.3 of the xHCI specification, the size of an isoch transfer should be `Packet Size * (Max Burst Size + 1) * (Mult + 1) = 6144`. + +However, the host-libusb.pcapng capture shows that each transfer is only 1024 bytes in size. + +For higher bitrate formats, it is observed that the system generates erroneous transfers in which the data offset in the isodescriptor exceeds the packet size. + +Currently, I am unsure of the cause of this issue. If you need any additional information, logs, or specific USB packet captures, I would be more than happy to provide them. + +Thanks +Additional information: +[lsusb-cam-SuperSpeed.txt](/uploads/712ac9e67d0b53ce46573bee3df883d0/lsusb-cam-SuperSpeed.txt) +[lsusb-cam-HighSpeed.txt](/uploads/70f855e471714fb1b48a7ed7912c0be4/lsusb-cam-HighSpeed.txt) diff --git a/results/classifier/zero-shot/108/none/1616706 b/results/classifier/zero-shot/108/none/1616706 new file mode 100644 index 000000000..db58afe60 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1616706 @@ -0,0 +1,36 @@ +device: 0.590 +semantic: 0.537 +performance: 0.531 +graphic: 0.488 +other: 0.465 +network: 0.455 +permissions: 0.410 +socket: 0.361 +KVM: 0.333 +files: 0.309 +vnc: 0.296 +boot: 0.286 +PID: 0.271 +debug: 0.268 + +watchdog doesn't bring down the VM + +Qemu-kvm version : QEMU emulator version 1.5.3 (qemu-kvm-1.5.3-105.el7), Copyright (c) 2003-2008 Fabrice Billard + +Qemu version: Virsh command line tool of libvirt 1.2.17 + +I have the VM stuck in bios (efi shell), but i don't see the watchdog in the host bringing it down? + +Couple of questions: + +1. Does the watchdog functionality requires the driver in adminvm to trigger the reload? or qemu detects it in the host and causes the reload. + +2. Does this work reliably? I have seen cases where in i have the watchdog daemon in the VM shut, still don't see the VM going down (I put the action in the XML file as power off) + +Thanks +Amit + +qemu-kvm-1.5.3-105.el7 isn't supported by the upstream community; if you need support with this Red Hat version, you'll have to go through Red Hat. + +The most recent version of qemu supported upstream is 2.6.1 and soon, 2.7.0. + diff --git a/results/classifier/zero-shot/108/none/1617 b/results/classifier/zero-shot/108/none/1617 new file mode 100644 index 000000000..d40017970 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1617 @@ -0,0 +1,77 @@ +graphic: 0.414 +semantic: 0.410 +vnc: 0.362 +other: 0.354 +permissions: 0.353 +debug: 0.320 +performance: 0.288 +device: 0.268 +PID: 0.261 +network: 0.242 +KVM: 0.207 +socket: 0.203 +boot: 0.191 +files: 0.152 + +RISC-V: VS external IRQ can be taken in M-mode +Description of problem: +The RISC-V specification states that `VS-level interrupts and guest external interrupts are always delegated past M-mode to HS mode.` +I happened to come across a situation where QEMU takes the vs_external IRQ in machine mode. +Steps to reproduce: +1. Enable IRQs globally (mstatus, vsstatus) +2. Set hstatus.VGEIN to a legal value +3. Write -1 to mie +4. Write -1 to hvip + +I included a binary that should be able to reproduce the issue. + +I use a vectored setup for mtvec and as soon as the VSEIP bit in hvip has been set the machine jumps to mtvec.vsei. +To confirm that I actually went to mtvec and not somewhere with a faulty print I also performed an ecall and that was reported as an M mode ecall. +Additional information: +``` +TRACE: [hart_ctrl.c:35] STARTING CPU 0 +DEBUG: [trap_handling.c: 886] Setting up trap handlers +DEBUG: [aia_ctrl.c: 377] Initializing interrupt controller +TRACE: [main.c:31] Writing -1 to mie +TRACE: [main.c:33] Writing -1 to hvip +riscv_cpu_do_interrupt: hart:0, async:1, cause:000000000000000a, epc:0x0000000080000114, tval:0x0000000000000000, desc=vs_external +ERROR: [trap_handling.c:280] mtvec_vsei should be unreachable +mstatus = 0x0000000a000038a2 hstatus: + SIE = 1 VSXL[1:0] = 2 + MIE = 0 VTSR = 0 + SPIE = 1 VTW = 0 + UBE = 0 VTVM = 0 + MPIE = 1 VGEIN[5:0] = 1 + SPP = 0 HU = 0 + VS = 0 SPVP = 0 + MPP = 3 SPV = 0 + FS = 1 GVA = 0 + MPRV = 0 VSBE = 0 + SUM = 0 + MXR = 0 + TVM = 0 + TW = 0 + TSR = 0 + UXL = 2 + SXL = 2 + SBE = 0 + MBE = 0 + GVA = 0 + MPV = 0 +mie mip mideleg hvip + ssie (1) = 1 ssip (1) = 0 ssi (1) = 0 ssip (1) = 0 + vssie(2) = 1 vssip(2) = 1 vssi (2) = 0 vssip(2) = 1 + msie (3) = 1 msip (3) = 0 msi (3) = 0 msip (3) = 0 + stie (5) = 1 stip (5) = 0 sti (5) = 0 stip (5) = 0 + vstie(6) = 1 vstip(6) = 0 vsti (6) = 0 vstip(6) = 0 + mtie (7) = 1 mtip (7) = 0 mti (7) = 0 mtip (7) = 0 + seie (9) = 1 seip (9) = 0 sei (9) = 0 seip (9) = 0 + vseie(10) = 1 vseip(10) = 1 vsei (10) = 0 vseip(10) = 1 + meie (11) = 1 meip (11) = 0 mei (11) = 0 meip (11) = 0 + sgeie(12) = 1 sgeip(12) = 0 sgei (12) = 0 sgeip(12) = 0 +DEBUG: [trap_handling.c: 28] hart_ctrl.kill_hart = 0x8000a00c +TRACE: [trap_handling.c:29] Program done, exiting +QEMU: Terminated +``` +Reproducer of the problem: +[main](/uploads/26a5698ce948149ca9d34f6b3dfac6a4/main) diff --git a/results/classifier/zero-shot/108/none/1618301 b/results/classifier/zero-shot/108/none/1618301 new file mode 100644 index 000000000..2f6ef98eb --- /dev/null +++ b/results/classifier/zero-shot/108/none/1618301 @@ -0,0 +1,66 @@ +graphic: 0.426 +device: 0.400 +other: 0.358 +performance: 0.344 +socket: 0.335 +PID: 0.330 +semantic: 0.222 +permissions: 0.216 +boot: 0.210 +network: 0.198 +vnc: 0.191 +debug: 0.138 +KVM: 0.126 +files: 0.102 + +qemu-input: Mouse stops working in Windows guest + +ROCCAT Kone XTD mouse will randomly stop working in the guest until it's restarted. Windows Event Viewer shows an error in i8042prt, with the message "Could not set the mouse resolution". The XML log: + +- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> +- <System> + <Provider Name="i8042prt" /> + <EventID Qualifiers="49157">23</EventID> + <Level>2</Level> + <Task>0</Task> + <Keywords>0x80000000000000</Keywords> + <TimeCreated SystemTime="2016-08-30T02:52:00.354536300Z" /> + <EventRecordID>5708</EventRecordID> + <Channel>System</Channel> + <Computer>cronus</Computer> + <Security /> + </System> +- <EventData> + <Data /> + <Binary>000008000100000000000000170005C03205000000000000000000000000000000000000000000000000000000000000</Binary> + </EventData> + </Event> + +Host is running Linux 4.7.2 with QEMU 2.6.1. + +The same with: + 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux +QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7) +and + +Windows 4.0 sp6 workstation. + +This guest worked in virtualbox without issues. + +Still exists in QEMU emulator version 5.0.0 (Debian 1:5.0-5) running on Linux 5.6.0-1-amd64 #1 SMP Debian 5.6.7-1 (2020-04-29) x86_64 GNU/Linux + + +Another observation (not sure if 100% relevant) +When I leave "Generic PS/2 mouse" as an ONLY pointing device, I can observe erratic moving ("jumping") cursor in (at least) windows guests (NT4 sp 6 , XP, Win 8.1) + +QEMU emulator version 5.0.0 (Debian 1:5.0-6) + + + +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/126 + + diff --git a/results/classifier/zero-shot/108/none/1621 b/results/classifier/zero-shot/108/none/1621 new file mode 100644 index 000000000..c51ceb151 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1621 @@ -0,0 +1,121 @@ +other: 0.535 +KVM: 0.520 +permissions: 0.475 +debug: 0.442 +performance: 0.442 +vnc: 0.437 +device: 0.433 +boot: 0.431 +graphic: 0.428 +semantic: 0.401 +PID: 0.400 +socket: 0.378 +files: 0.376 +network: 0.341 + +QCOW2 image grows over 110% of its virtual size +Description of problem: +Follow-up of https://github.com/oVirt/vdsm/issues/371 + +As oVirt divides a iSCSI LUN into a LVM device and each VM disk is a Logical Volume, the qcow2 images are inside a LV. +This works fine, and oVirt allows the LV to grow to 110% of its virtual size. + +Now we have like 1 time each month the issue that a VM tries to grow over its 110% limit, which should never happen. +Steps to reproduce: +1. When it happend in production, I copied the LV via dd to some file. +2. I copied the file to a new LV on a test machine, and created a VM for it +3. Start the VM +4. Issue reoccurs directly +Additional information: +So I started some gdb'ing on the pid, and this it what seems to happen: +``` +#16 0x0000563c60921f25 in qcow2_add_task (bs=bs@entry=0x563c62bb8090, pool=pool@entry=0x0, func=func@entry=0x563c60924860 <qcow2_co_pwritev_task_entry>, subcluster_type=subcluster_type@entry=QCOW2_SUBCLUSTER_UNALLOCATED_PLAIN, host_offset=17718824960, offset=offset@entry=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=0, l2meta=0x7f84c401c600) + at ../block/qcow2.c:2249 + local_task = {task = {pool = 0x0, func = 0x563c60924860 <qcow2_co_pwritev_task_entry>, ret = 0}, bs = 0x563c62bb8090, subcluster_type = QCOW2_SUBCLUSTER_UNALLOCATED_PLAIN, host_offset = 17718824960, offset = 15192346624, bytes = 1310720, qiov = 0x7f84c4003a70, qiov_offset = 0, l2meta = 0x7f84c401c600} + task = 0x7f82bafffb00 +#17 0x0000563c609225b7 in qcow2_co_pwritev_part (bs=0x563c62bb8090, offset=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=0, flags=<optimized out>) at ../block/qcow2.c:2645 + s = 0x563c62bbf990 + offset_in_cluster = <optimized out> + ret = <optimized out> + cur_bytes = 1310720 + host_offset = 17718824960 + l2meta = 0x7f84c401c600 + aio = 0x0 +#18 0x0000563c6090395b in bdrv_driver_pwritev (bs=bs@entry=0x563c62bb8090, offset=offset@entry=15192346624, bytes=bytes@entry=1310720, qiov=qiov@entry=0x7f84c4003a70, qiov_offset=qiov_offset@entry=0, flags=flags@entry=0) at ../block/io.c:1248 + drv = 0x563c6125fb20 <bdrv_qcow2> + sector_num = <optimized out> + nb_sectors = <optimized out> + local_qiov = {iov = 0x563c6125fb20 <bdrv_qcow2>, niov = 8192, {{nalloc = 4096, local_iov = {iov_base = 0x563c62bb8090, iov_len = 0}}, {__pad = "\000\020\000\000\000\000\000\000\220\200\273b", size = 0}}} + ret = <optimized out> + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#19 0x0000563c60905872 in bdrv_aligned_pwritev (child=0x563c647f3c10, req=0x7f82bafffe30, offset=15192346624, bytes=1310720, align=<optimized out>, qiov=0x7f84c4003a70, qiov_offset=0, flags=0) at ../block/io.c:2122 + bs = 0x563c62bb8090 + drv = 0x563c6125fb20 <bdrv_qcow2> + ret = <optimized out> + bytes_remaining = 1310720 + max_transfer = <optimized out> + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#20 0x0000563c6090622b in bdrv_co_pwritev_part (child=0x563c647f3c10, offset=<optimized out>, offset@entry=15192346624, bytes=<optimized out>, bytes@entry=1310720, qiov=<optimized out>, qiov@entry=0x7f84c4003a70, qiov_offset=<optimized out>, qiov_offset@entry=0, flags=flags@entry=0) at ../block/io.c:2310 + bs = <optimized out> + req = {bs = 0x563c62bb8090, offset = 15192346624, bytes = 1310720, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 15192346624, overlap_bytes = 1310720, list = {le_next = 0x7f829c6c8e30, le_prev = 0x7f82a3fffe60}, co = 0x7f84c4004210, wait_queue = {entries = {sqh_first = 0x0, sqh_last = 0x7f82bafffe78}}, waiting_for = 0x0} + align = <optimized out> + pad = {buf = 0x0, buf_len = 0, tail_buf = 0x0, head = 0, tail = 0, merge_reads = false, local_qiov = {iov = 0x0, niov = 0, {{nalloc = 0, local_iov = {iov_base = 0x0, iov_len = 0}}, {__pad = '\000' <repeats 11 times>, size = 0}}}} + ret = <optimized out> + padded = false + __PRETTY_FUNCTION__ = "bdrv_co_pwritev_part" +#21 0x0000563c608f71e0 in blk_co_do_pwritev_part (blk=0x563c648183c0, offset=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=qiov_offset@entry=0, flags=0) at ../block/block-backend.c:1289 + ret = <optimized out> + bs = 0x563c62bb8090 +``` + +There is a write from the VM with size 1310720 on offset 15192346624. +A host offset is calculated for this, but this offset is 17718824960 !! +The image/LV is only 17716740096, and 17716740096 < 17718824960 -> ENOSPC error is triggered. + +The code for calculating the host offset seems to be untouched for the last years. +But it seems like for some reason it takes some offset way beyond the virtual size boundaries. + +The qemu-img output: +``` +# qemu-img info /dev/mapper/test-xxxxx +image: /dev/mapper/test-xxxxx +file format: qcow2 +virtual size: 15 GiB (16106127360 bytes) +disk size: 0 B +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + bitmaps: + [0]: + flags: + [0]: in-use + [1]: auto + name: 428fae80-3892-4083-9107-51fb76a7f06b + granularity: 65536 + [1]: + flags: + [0]: in-use + [1]: auto + name: 51ccd1fc-08a4-485d-8c04-0eb750665e05 + granularity: 65536 + [2]: + flags: + [0]: in-use + [1]: auto + name: 19796bed-56a5-44c1-a7f2-dae633e65c87 + granularity: 65536 + [3]: + flags: + [0]: in-use + [1]: auto + name: 13056186-e65e-448e-a3c3-019ab25d3a27 + granularity: 65536 + refcount bits: 16 + corrupt: false + extended l2: false +``` + +Also attaching the map where you can see there are plenty of zero blocks, but still it tries to allocate a new block for some reason. +[map.txt](/uploads/0890cf718f77c0ad2e562165eb350d13/map.txt) diff --git a/results/classifier/zero-shot/108/none/16228234 b/results/classifier/zero-shot/108/none/16228234 new file mode 100644 index 000000000..074253f52 --- /dev/null +++ b/results/classifier/zero-shot/108/none/16228234 @@ -0,0 +1,1854 @@ +other: 0.535 +KVM: 0.445 +network: 0.440 +permissions: 0.439 +device: 0.439 +vnc: 0.420 +semantic: 0.411 +performance: 0.409 +graphic: 0.408 +boot: 0.402 +socket: 0.401 +files: 0.394 +PID: 0.385 +debug: 0.384 + +[Qemu-devel] [Bug?] BQL about live migration + +Hello Juan & Dave, + +We hit a bug in our test: +Network error occurs when migrating a guest, libvirt then rollback the +migration, causes qemu coredump +qemu log: +2017-03-01T12:54:33.904949+08:00|info|qemu[17672]|[33614]|monitor_qapi_event_emit[479]|: + {"timestamp": {"seconds": 1488344073, "microseconds": 904914}, "event": "STOP"} +2017-03-01T12:54:37.522500+08:00|info|qemu[17672]|[17672]|handle_qmp_command[3930]|: + qmp_cmd_name: migrate_cancel +2017-03-01T12:54:37.522607+08:00|info|qemu[17672]|[17672]|monitor_qapi_event_emit[479]|: + {"timestamp": {"seconds": 1488344077, "microseconds": 522556}, "event": +"MIGRATION", "data": {"status": "cancelling"}} +2017-03-01T12:54:37.524671+08:00|info|qemu[17672]|[17672]|handle_qmp_command[3930]|: + qmp_cmd_name: cont +2017-03-01T12:54:37.524733+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: + virtio-balloon device status is 7 that means DRIVER OK +2017-03-01T12:54:37.525434+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: + virtio-net device status is 7 that means DRIVER OK +2017-03-01T12:54:37.525484+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: + virtio-blk device status is 7 that means DRIVER OK +2017-03-01T12:54:37.525562+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: + virtio-serial device status is 7 that means DRIVER OK +2017-03-01T12:54:37.527653+08:00|info|qemu[17672]|[17672]|vm_start[981]|: +vm_state-notify:3ms +2017-03-01T12:54:37.528523+08:00|info|qemu[17672]|[17672]|monitor_qapi_event_emit[479]|: + {"timestamp": {"seconds": 1488344077, "microseconds": 527699}, "event": +"RESUME"} +2017-03-01T12:54:37.530680+08:00|info|qemu[17672]|[33614]|migration_bitmap_sync[720]|: + this iteration cycle takes 3s, new dirtied data:0MB +2017-03-01T12:54:37.530909+08:00|info|qemu[17672]|[33614]|monitor_qapi_event_emit[479]|: + {"timestamp": {"seconds": 1488344077, "microseconds": 530733}, "event": +"MIGRATION_PASS", "data": {"pass": 3}} +2017-03-01T04:54:37.530997Z qemu-kvm: socket_writev_buffer: Got err=32 for +(131583/18446744073709551615) +qemu-kvm: /home/abuild/rpmbuild/BUILD/qemu-kvm-2.6.0/hw/net/virtio_net.c:1519: +virtio_net_save: Assertion `!n->vhost_started' failed. +2017-03-01 12:54:43.028: shutting down + +> +From qemu log, qemu received and processed migrate_cancel/cont qmp commands +after guest been stopped and entered the last round of migration. Then +migration thread try to save device state when guest is running(started by +cont command), causes assert and coredump. +This is because in last iter, we call cpu_synchronize_all_states() to +synchronize vcpu states, this call will release qemu_global_mutex and wait +for do_kvm_cpu_synchronize_state() to be executed on target vcpu: +(gdb) bt +#0 0x00007f763d1046d5 in pthread_cond_wait@@GLIBC_2.3.2 () from +/lib64/libpthread.so.0 +#1 0x00007f7643e51d7f in qemu_cond_wait (cond=0x7f764445eca0 <qemu_work_cond>, +mutex=0x7f764445eba0 <qemu_global_mutex>) at util/qemu-thread-posix.c:132 +#2 0x00007f7643a2e154 in run_on_cpu (cpu=0x7f7644e06d80, func=0x7f7643a46413 +<do_kvm_cpu_synchronize_state>, data=0x7f7644e06d80) at +/mnt/public/yanghy/qemu-kvm/cpus.c:995 +#3 0x00007f7643a46487 in kvm_cpu_synchronize_state (cpu=0x7f7644e06d80) at +/mnt/public/yanghy/qemu-kvm/kvm-all.c:1805 +#4 0x00007f7643a2c700 in cpu_synchronize_state (cpu=0x7f7644e06d80) at +/mnt/public/yanghy/qemu-kvm/include/sysemu/kvm.h:457 +#5 0x00007f7643a2db0c in cpu_synchronize_all_states () at +/mnt/public/yanghy/qemu-kvm/cpus.c:766 +#6 0x00007f7643a67b5b in qemu_savevm_state_complete_precopy (f=0x7f76462f2d30, +iterable_only=false) at /mnt/public/yanghy/qemu-kvm/migration/savevm.c:1051 +#7 0x00007f7643d121e9 in migration_completion (s=0x7f76443e78c0 +<current_migration.37571>, current_active_state=4, +old_vm_running=0x7f74343fda00, start_time=0x7f74343fda08) at +migration/migration.c:1753 +#8 0x00007f7643d126c5 in migration_thread (opaque=0x7f76443e78c0 +<current_migration.37571>) at migration/migration.c:1922 +#9 0x00007f763d100dc5 in start_thread () from /lib64/libpthread.so.0 +#10 0x00007f763ce2e71d in clone () from /lib64/libc.so.6 +(gdb) p iothread_locked +$1 = true + +and then, qemu main thread been executed, it won't block because migration +thread released the qemu_global_mutex: +(gdb) thr 1 +[Switching to thread 1 (Thread 0x7fe298e08bc0 (LWP 30767))] +#0 os_host_main_loop_wait (timeout=931565) at main-loop.c:270 +270 QEMU_LOG(LOG_INFO,"***** after qemu_pool_ns: timeout %d\n", +timeout); +(gdb) p iothread_locked +$2 = true +(gdb) l 268 +263 +264 ret = qemu_poll_ns((GPollFD *)gpollfds->data, gpollfds->len, +timeout); +265 +266 +267 if (timeout) { +268 qemu_mutex_lock_iothread(); +269 if (runstate_check(RUN_STATE_FINISH_MIGRATE)) { +270 QEMU_LOG(LOG_INFO,"***** after qemu_pool_ns: timeout %d\n", +timeout); +271 } +272 } +(gdb) + +So, although we've hold iothread_lock in stop© phase of migration, we +can't guarantee the iothread been locked all through the stop & copy phase, +any thoughts on how to solve this problem? + + +Thanks, +-Gonglei + +On Fri, 03/03 09:29, Gonglei (Arei) wrote: +> +Hello Juan & Dave, +> +> +We hit a bug in our test: +> +Network error occurs when migrating a guest, libvirt then rollback the +> +migration, causes qemu coredump +> +qemu log: +> +2017-03-01T12:54:33.904949+08:00|info|qemu[17672]|[33614]|monitor_qapi_event_emit[479]|: +> +{"timestamp": {"seconds": 1488344073, "microseconds": 904914}, "event": +> +"STOP"} +> +2017-03-01T12:54:37.522500+08:00|info|qemu[17672]|[17672]|handle_qmp_command[3930]|: +> +qmp_cmd_name: migrate_cancel +> +2017-03-01T12:54:37.522607+08:00|info|qemu[17672]|[17672]|monitor_qapi_event_emit[479]|: +> +{"timestamp": {"seconds": 1488344077, "microseconds": 522556}, "event": +> +"MIGRATION", "data": {"status": "cancelling"}} +> +2017-03-01T12:54:37.524671+08:00|info|qemu[17672]|[17672]|handle_qmp_command[3930]|: +> +qmp_cmd_name: cont +> +2017-03-01T12:54:37.524733+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +virtio-balloon device status is 7 that means DRIVER OK +> +2017-03-01T12:54:37.525434+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +virtio-net device status is 7 that means DRIVER OK +> +2017-03-01T12:54:37.525484+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +virtio-blk device status is 7 that means DRIVER OK +> +2017-03-01T12:54:37.525562+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +virtio-serial device status is 7 that means DRIVER OK +> +2017-03-01T12:54:37.527653+08:00|info|qemu[17672]|[17672]|vm_start[981]|: +> +vm_state-notify:3ms +> +2017-03-01T12:54:37.528523+08:00|info|qemu[17672]|[17672]|monitor_qapi_event_emit[479]|: +> +{"timestamp": {"seconds": 1488344077, "microseconds": 527699}, "event": +> +"RESUME"} +> +2017-03-01T12:54:37.530680+08:00|info|qemu[17672]|[33614]|migration_bitmap_sync[720]|: +> +this iteration cycle takes 3s, new dirtied data:0MB +> +2017-03-01T12:54:37.530909+08:00|info|qemu[17672]|[33614]|monitor_qapi_event_emit[479]|: +> +{"timestamp": {"seconds": 1488344077, "microseconds": 530733}, "event": +> +"MIGRATION_PASS", "data": {"pass": 3}} +> +2017-03-01T04:54:37.530997Z qemu-kvm: socket_writev_buffer: Got err=32 for +> +(131583/18446744073709551615) +> +qemu-kvm: +> +/home/abuild/rpmbuild/BUILD/qemu-kvm-2.6.0/hw/net/virtio_net.c:1519: +> +virtio_net_save: Assertion `!n->vhost_started' failed. +> +2017-03-01 12:54:43.028: shutting down +> +> +From qemu log, qemu received and processed migrate_cancel/cont qmp commands +> +after guest been stopped and entered the last round of migration. Then +> +migration thread try to save device state when guest is running(started by +> +cont command), causes assert and coredump. +> +This is because in last iter, we call cpu_synchronize_all_states() to +> +synchronize vcpu states, this call will release qemu_global_mutex and wait +> +for do_kvm_cpu_synchronize_state() to be executed on target vcpu: +> +(gdb) bt +> +#0 0x00007f763d1046d5 in pthread_cond_wait@@GLIBC_2.3.2 () from +> +/lib64/libpthread.so.0 +> +#1 0x00007f7643e51d7f in qemu_cond_wait (cond=0x7f764445eca0 +> +<qemu_work_cond>, mutex=0x7f764445eba0 <qemu_global_mutex>) at +> +util/qemu-thread-posix.c:132 +> +#2 0x00007f7643a2e154 in run_on_cpu (cpu=0x7f7644e06d80, func=0x7f7643a46413 +> +<do_kvm_cpu_synchronize_state>, data=0x7f7644e06d80) at +> +/mnt/public/yanghy/qemu-kvm/cpus.c:995 +> +#3 0x00007f7643a46487 in kvm_cpu_synchronize_state (cpu=0x7f7644e06d80) at +> +/mnt/public/yanghy/qemu-kvm/kvm-all.c:1805 +> +#4 0x00007f7643a2c700 in cpu_synchronize_state (cpu=0x7f7644e06d80) at +> +/mnt/public/yanghy/qemu-kvm/include/sysemu/kvm.h:457 +> +#5 0x00007f7643a2db0c in cpu_synchronize_all_states () at +> +/mnt/public/yanghy/qemu-kvm/cpus.c:766 +> +#6 0x00007f7643a67b5b in qemu_savevm_state_complete_precopy +> +(f=0x7f76462f2d30, iterable_only=false) at +> +/mnt/public/yanghy/qemu-kvm/migration/savevm.c:1051 +> +#7 0x00007f7643d121e9 in migration_completion (s=0x7f76443e78c0 +> +<current_migration.37571>, current_active_state=4, +> +old_vm_running=0x7f74343fda00, start_time=0x7f74343fda08) at +> +migration/migration.c:1753 +> +#8 0x00007f7643d126c5 in migration_thread (opaque=0x7f76443e78c0 +> +<current_migration.37571>) at migration/migration.c:1922 +> +#9 0x00007f763d100dc5 in start_thread () from /lib64/libpthread.so.0 +> +#10 0x00007f763ce2e71d in clone () from /lib64/libc.so.6 +> +(gdb) p iothread_locked +> +$1 = true +> +> +and then, qemu main thread been executed, it won't block because migration +> +thread released the qemu_global_mutex: +> +(gdb) thr 1 +> +[Switching to thread 1 (Thread 0x7fe298e08bc0 (LWP 30767))] +> +#0 os_host_main_loop_wait (timeout=931565) at main-loop.c:270 +> +270 QEMU_LOG(LOG_INFO,"***** after qemu_pool_ns: timeout +> +%d\n", timeout); +> +(gdb) p iothread_locked +> +$2 = true +> +(gdb) l 268 +> +263 +> +264 ret = qemu_poll_ns((GPollFD *)gpollfds->data, gpollfds->len, +> +timeout); +> +265 +> +266 +> +267 if (timeout) { +> +268 qemu_mutex_lock_iothread(); +> +269 if (runstate_check(RUN_STATE_FINISH_MIGRATE)) { +> +270 QEMU_LOG(LOG_INFO,"***** after qemu_pool_ns: timeout +> +%d\n", timeout); +> +271 } +> +272 } +> +(gdb) +> +> +So, although we've hold iothread_lock in stop© phase of migration, we +> +can't guarantee the iothread been locked all through the stop & copy phase, +> +any thoughts on how to solve this problem? +Could you post a backtrace of the assertion? + +Fam + +On 2017/3/3 18:42, Fam Zheng wrote: +> +On Fri, 03/03 09:29, Gonglei (Arei) wrote: +> +> Hello Juan & Dave, +> +> +> +> We hit a bug in our test: +> +> Network error occurs when migrating a guest, libvirt then rollback the +> +> migration, causes qemu coredump +> +> qemu log: +> +> 2017-03-01T12:54:33.904949+08:00|info|qemu[17672]|[33614]|monitor_qapi_event_emit[479]|: +> +> {"timestamp": {"seconds": 1488344073, "microseconds": 904914}, "event": +> +> "STOP"} +> +> 2017-03-01T12:54:37.522500+08:00|info|qemu[17672]|[17672]|handle_qmp_command[3930]|: +> +> qmp_cmd_name: migrate_cancel +> +> 2017-03-01T12:54:37.522607+08:00|info|qemu[17672]|[17672]|monitor_qapi_event_emit[479]|: +> +> {"timestamp": {"seconds": 1488344077, "microseconds": 522556}, "event": +> +> "MIGRATION", "data": {"status": "cancelling"}} +> +> 2017-03-01T12:54:37.524671+08:00|info|qemu[17672]|[17672]|handle_qmp_command[3930]|: +> +> qmp_cmd_name: cont +> +> 2017-03-01T12:54:37.524733+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +> virtio-balloon device status is 7 that means DRIVER OK +> +> 2017-03-01T12:54:37.525434+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +> virtio-net device status is 7 that means DRIVER OK +> +> 2017-03-01T12:54:37.525484+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +> virtio-blk device status is 7 that means DRIVER OK +> +> 2017-03-01T12:54:37.525562+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +> virtio-serial device status is 7 that means DRIVER OK +> +> 2017-03-01T12:54:37.527653+08:00|info|qemu[17672]|[17672]|vm_start[981]|: +> +> vm_state-notify:3ms +> +> 2017-03-01T12:54:37.528523+08:00|info|qemu[17672]|[17672]|monitor_qapi_event_emit[479]|: +> +> {"timestamp": {"seconds": 1488344077, "microseconds": 527699}, "event": +> +> "RESUME"} +> +> 2017-03-01T12:54:37.530680+08:00|info|qemu[17672]|[33614]|migration_bitmap_sync[720]|: +> +> this iteration cycle takes 3s, new dirtied data:0MB +> +> 2017-03-01T12:54:37.530909+08:00|info|qemu[17672]|[33614]|monitor_qapi_event_emit[479]|: +> +> {"timestamp": {"seconds": 1488344077, "microseconds": 530733}, "event": +> +> "MIGRATION_PASS", "data": {"pass": 3}} +> +> 2017-03-01T04:54:37.530997Z qemu-kvm: socket_writev_buffer: Got err=32 for +> +> (131583/18446744073709551615) +> +> qemu-kvm: +> +> /home/abuild/rpmbuild/BUILD/qemu-kvm-2.6.0/hw/net/virtio_net.c:1519: +> +> virtio_net_save: Assertion `!n->vhost_started' failed. +> +> 2017-03-01 12:54:43.028: shutting down +> +> +> +> From qemu log, qemu received and processed migrate_cancel/cont qmp commands +> +> after guest been stopped and entered the last round of migration. Then +> +> migration thread try to save device state when guest is running(started by +> +> cont command), causes assert and coredump. +> +> This is because in last iter, we call cpu_synchronize_all_states() to +> +> synchronize vcpu states, this call will release qemu_global_mutex and wait +> +> for do_kvm_cpu_synchronize_state() to be executed on target vcpu: +> +> (gdb) bt +> +> #0 0x00007f763d1046d5 in pthread_cond_wait@@GLIBC_2.3.2 () from +> +> /lib64/libpthread.so.0 +> +> #1 0x00007f7643e51d7f in qemu_cond_wait (cond=0x7f764445eca0 +> +> <qemu_work_cond>, mutex=0x7f764445eba0 <qemu_global_mutex>) at +> +> util/qemu-thread-posix.c:132 +> +> #2 0x00007f7643a2e154 in run_on_cpu (cpu=0x7f7644e06d80, +> +> func=0x7f7643a46413 <do_kvm_cpu_synchronize_state>, data=0x7f7644e06d80) at +> +> /mnt/public/yanghy/qemu-kvm/cpus.c:995 +> +> #3 0x00007f7643a46487 in kvm_cpu_synchronize_state (cpu=0x7f7644e06d80) at +> +> /mnt/public/yanghy/qemu-kvm/kvm-all.c:1805 +> +> #4 0x00007f7643a2c700 in cpu_synchronize_state (cpu=0x7f7644e06d80) at +> +> /mnt/public/yanghy/qemu-kvm/include/sysemu/kvm.h:457 +> +> #5 0x00007f7643a2db0c in cpu_synchronize_all_states () at +> +> /mnt/public/yanghy/qemu-kvm/cpus.c:766 +> +> #6 0x00007f7643a67b5b in qemu_savevm_state_complete_precopy +> +> (f=0x7f76462f2d30, iterable_only=false) at +> +> /mnt/public/yanghy/qemu-kvm/migration/savevm.c:1051 +> +> #7 0x00007f7643d121e9 in migration_completion (s=0x7f76443e78c0 +> +> <current_migration.37571>, current_active_state=4, +> +> old_vm_running=0x7f74343fda00, start_time=0x7f74343fda08) at +> +> migration/migration.c:1753 +> +> #8 0x00007f7643d126c5 in migration_thread (opaque=0x7f76443e78c0 +> +> <current_migration.37571>) at migration/migration.c:1922 +> +> #9 0x00007f763d100dc5 in start_thread () from /lib64/libpthread.so.0 +> +> #10 0x00007f763ce2e71d in clone () from /lib64/libc.so.6 +> +> (gdb) p iothread_locked +> +> $1 = true +> +> +> +> and then, qemu main thread been executed, it won't block because migration +> +> thread released the qemu_global_mutex: +> +> (gdb) thr 1 +> +> [Switching to thread 1 (Thread 0x7fe298e08bc0 (LWP 30767))] +> +> #0 os_host_main_loop_wait (timeout=931565) at main-loop.c:270 +> +> 270 QEMU_LOG(LOG_INFO,"***** after qemu_pool_ns: timeout +> +> %d\n", timeout); +> +> (gdb) p iothread_locked +> +> $2 = true +> +> (gdb) l 268 +> +> 263 +> +> 264 ret = qemu_poll_ns((GPollFD *)gpollfds->data, gpollfds->len, +> +> timeout); +> +> 265 +> +> 266 +> +> 267 if (timeout) { +> +> 268 qemu_mutex_lock_iothread(); +> +> 269 if (runstate_check(RUN_STATE_FINISH_MIGRATE)) { +> +> 270 QEMU_LOG(LOG_INFO,"***** after qemu_pool_ns: timeout +> +> %d\n", timeout); +> +> 271 } +> +> 272 } +> +> (gdb) +> +> +> +> So, although we've hold iothread_lock in stop© phase of migration, we +> +> can't guarantee the iothread been locked all through the stop & copy phase, +> +> any thoughts on how to solve this problem? +> +> +Could you post a backtrace of the assertion? +#0 0x00007f97b1fbe5d7 in raise () from /usr/lib64/libc.so.6 +#1 0x00007f97b1fbfcc8 in abort () from /usr/lib64/libc.so.6 +#2 0x00007f97b1fb7546 in __assert_fail_base () from /usr/lib64/libc.so.6 +#3 0x00007f97b1fb75f2 in __assert_fail () from /usr/lib64/libc.so.6 +#4 0x000000000049fd19 in virtio_net_save (f=0x7f97a8ca44d0, +opaque=0x7f97a86e9018) at /usr/src/debug/qemu-kvm-2.6.0/hw/ +#5 0x000000000047e380 in vmstate_save_old_style (address@hidden, +address@hidden, se=0x7f9 +#6 0x000000000047fb93 in vmstate_save (address@hidden, address@hidden, +address@hidden +#7 0x0000000000481ad2 in qemu_savevm_state_complete_precopy (f=0x7f97a8ca44d0, +address@hidden) +#8 0x00000000006c6b60 in migration_completion (address@hidden +<current_migration.38312>, current_active_state=curre + address@hidden) at migration/migration.c:1761 +#9 0x00000000006c71db in migration_thread (address@hidden +<current_migration.38312>) at migration/migrati + +> +> +Fam +> +-- +Thanks, +Yang + +* Gonglei (Arei) (address@hidden) wrote: +> +Hello Juan & Dave, +cc'ing in pbonzini since it's magic involving cpu_synrhonize_all_states() + +> +We hit a bug in our test: +> +Network error occurs when migrating a guest, libvirt then rollback the +> +migration, causes qemu coredump +> +qemu log: +> +2017-03-01T12:54:33.904949+08:00|info|qemu[17672]|[33614]|monitor_qapi_event_emit[479]|: +> +{"timestamp": {"seconds": 1488344073, "microseconds": 904914}, "event": +> +"STOP"} +> +2017-03-01T12:54:37.522500+08:00|info|qemu[17672]|[17672]|handle_qmp_command[3930]|: +> +qmp_cmd_name: migrate_cancel +> +2017-03-01T12:54:37.522607+08:00|info|qemu[17672]|[17672]|monitor_qapi_event_emit[479]|: +> +{"timestamp": {"seconds": 1488344077, "microseconds": 522556}, "event": +> +"MIGRATION", "data": {"status": "cancelling"}} +> +2017-03-01T12:54:37.524671+08:00|info|qemu[17672]|[17672]|handle_qmp_command[3930]|: +> +qmp_cmd_name: cont +> +2017-03-01T12:54:37.524733+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +virtio-balloon device status is 7 that means DRIVER OK +> +2017-03-01T12:54:37.525434+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +virtio-net device status is 7 that means DRIVER OK +> +2017-03-01T12:54:37.525484+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +virtio-blk device status is 7 that means DRIVER OK +> +2017-03-01T12:54:37.525562+08:00|info|qemu[17672]|[17672]|virtio_set_status[725]|: +> +virtio-serial device status is 7 that means DRIVER OK +> +2017-03-01T12:54:37.527653+08:00|info|qemu[17672]|[17672]|vm_start[981]|: +> +vm_state-notify:3ms +> +2017-03-01T12:54:37.528523+08:00|info|qemu[17672]|[17672]|monitor_qapi_event_emit[479]|: +> +{"timestamp": {"seconds": 1488344077, "microseconds": 527699}, "event": +> +"RESUME"} +> +2017-03-01T12:54:37.530680+08:00|info|qemu[17672]|[33614]|migration_bitmap_sync[720]|: +> +this iteration cycle takes 3s, new dirtied data:0MB +> +2017-03-01T12:54:37.530909+08:00|info|qemu[17672]|[33614]|monitor_qapi_event_emit[479]|: +> +{"timestamp": {"seconds": 1488344077, "microseconds": 530733}, "event": +> +"MIGRATION_PASS", "data": {"pass": 3}} +> +2017-03-01T04:54:37.530997Z qemu-kvm: socket_writev_buffer: Got err=32 for +> +(131583/18446744073709551615) +> +qemu-kvm: +> +/home/abuild/rpmbuild/BUILD/qemu-kvm-2.6.0/hw/net/virtio_net.c:1519: +> +virtio_net_save: Assertion `!n->vhost_started' failed. +> +2017-03-01 12:54:43.028: shutting down +> +> +From qemu log, qemu received and processed migrate_cancel/cont qmp commands +> +after guest been stopped and entered the last round of migration. Then +> +migration thread try to save device state when guest is running(started by +> +cont command), causes assert and coredump. +> +This is because in last iter, we call cpu_synchronize_all_states() to +> +synchronize vcpu states, this call will release qemu_global_mutex and wait +> +for do_kvm_cpu_synchronize_state() to be executed on target vcpu: +> +(gdb) bt +> +#0 0x00007f763d1046d5 in pthread_cond_wait@@GLIBC_2.3.2 () from +> +/lib64/libpthread.so.0 +> +#1 0x00007f7643e51d7f in qemu_cond_wait (cond=0x7f764445eca0 +> +<qemu_work_cond>, mutex=0x7f764445eba0 <qemu_global_mutex>) at +> +util/qemu-thread-posix.c:132 +> +#2 0x00007f7643a2e154 in run_on_cpu (cpu=0x7f7644e06d80, func=0x7f7643a46413 +> +<do_kvm_cpu_synchronize_state>, data=0x7f7644e06d80) at +> +/mnt/public/yanghy/qemu-kvm/cpus.c:995 +> +#3 0x00007f7643a46487 in kvm_cpu_synchronize_state (cpu=0x7f7644e06d80) at +> +/mnt/public/yanghy/qemu-kvm/kvm-all.c:1805 +> +#4 0x00007f7643a2c700 in cpu_synchronize_state (cpu=0x7f7644e06d80) at +> +/mnt/public/yanghy/qemu-kvm/include/sysemu/kvm.h:457 +> +#5 0x00007f7643a2db0c in cpu_synchronize_all_states () at +> +/mnt/public/yanghy/qemu-kvm/cpus.c:766 +> +#6 0x00007f7643a67b5b in qemu_savevm_state_complete_precopy +> +(f=0x7f76462f2d30, iterable_only=false) at +> +/mnt/public/yanghy/qemu-kvm/migration/savevm.c:1051 +> +#7 0x00007f7643d121e9 in migration_completion (s=0x7f76443e78c0 +> +<current_migration.37571>, current_active_state=4, +> +old_vm_running=0x7f74343fda00, start_time=0x7f74343fda08) at +> +migration/migration.c:1753 +> +#8 0x00007f7643d126c5 in migration_thread (opaque=0x7f76443e78c0 +> +<current_migration.37571>) at migration/migration.c:1922 +> +#9 0x00007f763d100dc5 in start_thread () from /lib64/libpthread.so.0 +> +#10 0x00007f763ce2e71d in clone () from /lib64/libc.so.6 +> +(gdb) p iothread_locked +> +$1 = true +> +> +and then, qemu main thread been executed, it won't block because migration +> +thread released the qemu_global_mutex: +> +(gdb) thr 1 +> +[Switching to thread 1 (Thread 0x7fe298e08bc0 (LWP 30767))] +> +#0 os_host_main_loop_wait (timeout=931565) at main-loop.c:270 +> +270 QEMU_LOG(LOG_INFO,"***** after qemu_pool_ns: timeout +> +%d\n", timeout); +> +(gdb) p iothread_locked +> +$2 = true +> +(gdb) l 268 +> +263 +> +264 ret = qemu_poll_ns((GPollFD *)gpollfds->data, gpollfds->len, +> +timeout); +> +265 +> +266 +> +267 if (timeout) { +> +268 qemu_mutex_lock_iothread(); +> +269 if (runstate_check(RUN_STATE_FINISH_MIGRATE)) { +> +270 QEMU_LOG(LOG_INFO,"***** after qemu_pool_ns: timeout +> +%d\n", timeout); +> +271 } +> +272 } +> +(gdb) +> +> +So, although we've hold iothread_lock in stop© phase of migration, we +> +can't guarantee the iothread been locked all through the stop & copy phase, +> +any thoughts on how to solve this problem? +Ouch that's pretty nasty; I remember Paolo explaining to me a while ago that +their were times when run_on_cpu would have to drop the BQL and I worried about +it, +but this is the 1st time I've seen an error due to it. + +Do you know what the migration state was at that point? Was it +MIGRATION_STATUS_CANCELLING? +I'm thinking perhaps we should stop 'cont' from continuing while migration is in +MIGRATION_STATUS_CANCELLING. Do we send an event when we hit CANCELLED - so +that +perhaps libvirt could avoid sending the 'cont' until then? + +Dave + + +> +> +Thanks, +> +-Gonglei +> +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +On 03/03/2017 13:00, Dr. David Alan Gilbert wrote: +> +Ouch that's pretty nasty; I remember Paolo explaining to me a while ago that +> +their were times when run_on_cpu would have to drop the BQL and I worried +> +about it, +> +but this is the 1st time I've seen an error due to it. +> +> +Do you know what the migration state was at that point? Was it +> +MIGRATION_STATUS_CANCELLING? +> +I'm thinking perhaps we should stop 'cont' from continuing while migration is +> +in +> +MIGRATION_STATUS_CANCELLING. Do we send an event when we hit CANCELLED - so +> +that +> +perhaps libvirt could avoid sending the 'cont' until then? +No, there's no event, though I thought libvirt would poll until +"query-migrate" returns the cancelled state. Of course that is a small +consolation, because a segfault is unacceptable. + +One possibility is to suspend the monitor in qmp_migrate_cancel and +resume it (with add_migration_state_change_notifier) when we hit the +CANCELLED state. I'm not sure what the latency would be between the end +of migrate_fd_cancel and finally reaching CANCELLED. + +Paolo + +* Paolo Bonzini (address@hidden) wrote: +> +> +> +On 03/03/2017 13:00, Dr. David Alan Gilbert wrote: +> +> Ouch that's pretty nasty; I remember Paolo explaining to me a while ago that +> +> their were times when run_on_cpu would have to drop the BQL and I worried +> +> about it, +> +> but this is the 1st time I've seen an error due to it. +> +> +> +> Do you know what the migration state was at that point? Was it +> +> MIGRATION_STATUS_CANCELLING? +> +> I'm thinking perhaps we should stop 'cont' from continuing while migration +> +> is in +> +> MIGRATION_STATUS_CANCELLING. Do we send an event when we hit CANCELLED - +> +> so that +> +> perhaps libvirt could avoid sending the 'cont' until then? +> +> +No, there's no event, though I thought libvirt would poll until +> +"query-migrate" returns the cancelled state. Of course that is a small +> +consolation, because a segfault is unacceptable. +I think you might get an event if you set the new migrate capability called +'events' on! + +void migrate_set_state(int *state, int old_state, int new_state) +{ + if (atomic_cmpxchg(state, old_state, new_state) == old_state) { + trace_migrate_set_state(new_state); + migrate_generate_event(new_state); + } +} + +static void migrate_generate_event(int new_state) +{ + if (migrate_use_events()) { + qapi_event_send_migration(new_state, &error_abort); + } +} + +That event feature went in sometime after 2.3.0. + +> +One possibility is to suspend the monitor in qmp_migrate_cancel and +> +resume it (with add_migration_state_change_notifier) when we hit the +> +CANCELLED state. I'm not sure what the latency would be between the end +> +of migrate_fd_cancel and finally reaching CANCELLED. +I don't like suspending monitors; it can potentially take quite a significant +time to do a cancel. +How about making 'cont' fail if we're in CANCELLING? + +I'd really love to see the 'run_on_cpu' being more careful about the BQL; +we really need all of the rest of the devices to stay quiesced at times. + +Dave + +> +Paolo +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +On 03/03/2017 14:11, Dr. David Alan Gilbert wrote: +> +* Paolo Bonzini (address@hidden) wrote: +> +> +> +> +> +> On 03/03/2017 13:00, Dr. David Alan Gilbert wrote: +> +>> Ouch that's pretty nasty; I remember Paolo explaining to me a while ago that +> +>> their were times when run_on_cpu would have to drop the BQL and I worried +> +>> about it, +> +>> but this is the 1st time I've seen an error due to it. +> +>> +> +>> Do you know what the migration state was at that point? Was it +> +>> MIGRATION_STATUS_CANCELLING? +> +>> I'm thinking perhaps we should stop 'cont' from continuing while migration +> +>> is in +> +>> MIGRATION_STATUS_CANCELLING. Do we send an event when we hit CANCELLED - +> +>> so that +> +>> perhaps libvirt could avoid sending the 'cont' until then? +> +> +> +> No, there's no event, though I thought libvirt would poll until +> +> "query-migrate" returns the cancelled state. Of course that is a small +> +> consolation, because a segfault is unacceptable. +> +> +I think you might get an event if you set the new migrate capability called +> +'events' on! +> +> +void migrate_set_state(int *state, int old_state, int new_state) +> +{ +> +if (atomic_cmpxchg(state, old_state, new_state) == old_state) { +> +trace_migrate_set_state(new_state); +> +migrate_generate_event(new_state); +> +} +> +} +> +> +static void migrate_generate_event(int new_state) +> +{ +> +if (migrate_use_events()) { +> +qapi_event_send_migration(new_state, &error_abort); +> +} +> +} +> +> +That event feature went in sometime after 2.3.0. +> +> +> One possibility is to suspend the monitor in qmp_migrate_cancel and +> +> resume it (with add_migration_state_change_notifier) when we hit the +> +> CANCELLED state. I'm not sure what the latency would be between the end +> +> of migrate_fd_cancel and finally reaching CANCELLED. +> +> +I don't like suspending monitors; it can potentially take quite a significant +> +time to do a cancel. +> +How about making 'cont' fail if we're in CANCELLING? +Actually I thought that would be the case already (in fact CANCELLING is +internal only; the outside world sees it as "active" in query-migrate). + +Lei, what is the runstate? (That is, why did cont succeed at all)? + +Paolo + +> +I'd really love to see the 'run_on_cpu' being more careful about the BQL; +> +we really need all of the rest of the devices to stay quiesced at times. +That's not really possible, because of how condition variables work. :( + +* Paolo Bonzini (address@hidden) wrote: +> +> +> +On 03/03/2017 14:11, Dr. David Alan Gilbert wrote: +> +> * Paolo Bonzini (address@hidden) wrote: +> +>> +> +>> +> +>> On 03/03/2017 13:00, Dr. David Alan Gilbert wrote: +> +>>> Ouch that's pretty nasty; I remember Paolo explaining to me a while ago +> +>>> that +> +>>> their were times when run_on_cpu would have to drop the BQL and I worried +> +>>> about it, +> +>>> but this is the 1st time I've seen an error due to it. +> +>>> +> +>>> Do you know what the migration state was at that point? Was it +> +>>> MIGRATION_STATUS_CANCELLING? +> +>>> I'm thinking perhaps we should stop 'cont' from continuing while +> +>>> migration is in +> +>>> MIGRATION_STATUS_CANCELLING. Do we send an event when we hit CANCELLED - +> +>>> so that +> +>>> perhaps libvirt could avoid sending the 'cont' until then? +> +>> +> +>> No, there's no event, though I thought libvirt would poll until +> +>> "query-migrate" returns the cancelled state. Of course that is a small +> +>> consolation, because a segfault is unacceptable. +> +> +> +> I think you might get an event if you set the new migrate capability called +> +> 'events' on! +> +> +> +> void migrate_set_state(int *state, int old_state, int new_state) +> +> { +> +> if (atomic_cmpxchg(state, old_state, new_state) == old_state) { +> +> trace_migrate_set_state(new_state); +> +> migrate_generate_event(new_state); +> +> } +> +> } +> +> +> +> static void migrate_generate_event(int new_state) +> +> { +> +> if (migrate_use_events()) { +> +> qapi_event_send_migration(new_state, &error_abort); +> +> } +> +> } +> +> +> +> That event feature went in sometime after 2.3.0. +> +> +> +>> One possibility is to suspend the monitor in qmp_migrate_cancel and +> +>> resume it (with add_migration_state_change_notifier) when we hit the +> +>> CANCELLED state. I'm not sure what the latency would be between the end +> +>> of migrate_fd_cancel and finally reaching CANCELLED. +> +> +> +> I don't like suspending monitors; it can potentially take quite a +> +> significant +> +> time to do a cancel. +> +> How about making 'cont' fail if we're in CANCELLING? +> +> +Actually I thought that would be the case already (in fact CANCELLING is +> +internal only; the outside world sees it as "active" in query-migrate). +> +> +Lei, what is the runstate? (That is, why did cont succeed at all)? +I suspect it's RUN_STATE_FINISH_MIGRATE - we set that before we do the device +save, and that's what we get at the end of a migrate and it's legal to restart +from there. + +> +Paolo +> +> +> I'd really love to see the 'run_on_cpu' being more careful about the BQL; +> +> we really need all of the rest of the devices to stay quiesced at times. +> +> +That's not really possible, because of how condition variables work. :( +*Really* we need to find a solution to that - there's probably lots of +other things that can spring up in that small window other than the +'cont'. + +Dave + +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +On 03/03/2017 14:26, Dr. David Alan Gilbert wrote: +> +* Paolo Bonzini (address@hidden) wrote: +> +> +> +> +> +> On 03/03/2017 14:11, Dr. David Alan Gilbert wrote: +> +>> * Paolo Bonzini (address@hidden) wrote: +> +>>> +> +>>> +> +>>> On 03/03/2017 13:00, Dr. David Alan Gilbert wrote: +> +>>>> Ouch that's pretty nasty; I remember Paolo explaining to me a while ago +> +>>>> that +> +>>>> their were times when run_on_cpu would have to drop the BQL and I worried +> +>>>> about it, +> +>>>> but this is the 1st time I've seen an error due to it. +> +>>>> +> +>>>> Do you know what the migration state was at that point? Was it +> +>>>> MIGRATION_STATUS_CANCELLING? +> +>>>> I'm thinking perhaps we should stop 'cont' from continuing while +> +>>>> migration is in +> +>>>> MIGRATION_STATUS_CANCELLING. Do we send an event when we hit CANCELLED - +> +>>>> so that +> +>>>> perhaps libvirt could avoid sending the 'cont' until then? +> +>>> +> +>>> No, there's no event, though I thought libvirt would poll until +> +>>> "query-migrate" returns the cancelled state. Of course that is a small +> +>>> consolation, because a segfault is unacceptable. +> +>> +> +>> I think you might get an event if you set the new migrate capability called +> +>> 'events' on! +> +>> +> +>> void migrate_set_state(int *state, int old_state, int new_state) +> +>> { +> +>> if (atomic_cmpxchg(state, old_state, new_state) == old_state) { +> +>> trace_migrate_set_state(new_state); +> +>> migrate_generate_event(new_state); +> +>> } +> +>> } +> +>> +> +>> static void migrate_generate_event(int new_state) +> +>> { +> +>> if (migrate_use_events()) { +> +>> qapi_event_send_migration(new_state, &error_abort); +> +>> } +> +>> } +> +>> +> +>> That event feature went in sometime after 2.3.0. +> +>> +> +>>> One possibility is to suspend the monitor in qmp_migrate_cancel and +> +>>> resume it (with add_migration_state_change_notifier) when we hit the +> +>>> CANCELLED state. I'm not sure what the latency would be between the end +> +>>> of migrate_fd_cancel and finally reaching CANCELLED. +> +>> +> +>> I don't like suspending monitors; it can potentially take quite a +> +>> significant +> +>> time to do a cancel. +> +>> How about making 'cont' fail if we're in CANCELLING? +> +> +> +> Actually I thought that would be the case already (in fact CANCELLING is +> +> internal only; the outside world sees it as "active" in query-migrate). +> +> +> +> Lei, what is the runstate? (That is, why did cont succeed at all)? +> +> +I suspect it's RUN_STATE_FINISH_MIGRATE - we set that before we do the device +> +save, and that's what we get at the end of a migrate and it's legal to restart +> +from there. +Yeah, but I think we get there at the end of a failed migrate only. So +perhaps we can introduce a new state RUN_STATE_FAILED_MIGRATE and forbid +"cont" from finish-migrate (only allow it from failed-migrate)? + +Paolo + +> +> Paolo +> +> +> +>> I'd really love to see the 'run_on_cpu' being more careful about the BQL; +> +>> we really need all of the rest of the devices to stay quiesced at times. +> +> +> +> That's not really possible, because of how condition variables work. :( +> +> +*Really* we need to find a solution to that - there's probably lots of +> +other things that can spring up in that small window other than the +> +'cont'. +> +> +Dave +> +> +-- +> +Dr. David Alan Gilbert / address@hidden / Manchester, UK +> + +Hi Paolo, + +On Fri, Mar 3, 2017 at 9:33 PM, Paolo Bonzini <address@hidden> wrote: + +> +> +> +On 03/03/2017 14:26, Dr. David Alan Gilbert wrote: +> +> * Paolo Bonzini (address@hidden) wrote: +> +>> +> +>> +> +>> On 03/03/2017 14:11, Dr. David Alan Gilbert wrote: +> +>>> * Paolo Bonzini (address@hidden) wrote: +> +>>>> +> +>>>> +> +>>>> On 03/03/2017 13:00, Dr. David Alan Gilbert wrote: +> +>>>>> Ouch that's pretty nasty; I remember Paolo explaining to me a while +> +ago that +> +>>>>> their were times when run_on_cpu would have to drop the BQL and I +> +worried about it, +> +>>>>> but this is the 1st time I've seen an error due to it. +> +>>>>> +> +>>>>> Do you know what the migration state was at that point? Was it +> +MIGRATION_STATUS_CANCELLING? +> +>>>>> I'm thinking perhaps we should stop 'cont' from continuing while +> +migration is in +> +>>>>> MIGRATION_STATUS_CANCELLING. Do we send an event when we hit +> +CANCELLED - so that +> +>>>>> perhaps libvirt could avoid sending the 'cont' until then? +> +>>>> +> +>>>> No, there's no event, though I thought libvirt would poll until +> +>>>> "query-migrate" returns the cancelled state. Of course that is a +> +small +> +>>>> consolation, because a segfault is unacceptable. +> +>>> +> +>>> I think you might get an event if you set the new migrate capability +> +called +> +>>> 'events' on! +> +>>> +> +>>> void migrate_set_state(int *state, int old_state, int new_state) +> +>>> { +> +>>> if (atomic_cmpxchg(state, old_state, new_state) == old_state) { +> +>>> trace_migrate_set_state(new_state); +> +>>> migrate_generate_event(new_state); +> +>>> } +> +>>> } +> +>>> +> +>>> static void migrate_generate_event(int new_state) +> +>>> { +> +>>> if (migrate_use_events()) { +> +>>> qapi_event_send_migration(new_state, &error_abort); +> +>>> } +> +>>> } +> +>>> +> +>>> That event feature went in sometime after 2.3.0. +> +>>> +> +>>>> One possibility is to suspend the monitor in qmp_migrate_cancel and +> +>>>> resume it (with add_migration_state_change_notifier) when we hit the +> +>>>> CANCELLED state. I'm not sure what the latency would be between the +> +end +> +>>>> of migrate_fd_cancel and finally reaching CANCELLED. +> +>>> +> +>>> I don't like suspending monitors; it can potentially take quite a +> +significant +> +>>> time to do a cancel. +> +>>> How about making 'cont' fail if we're in CANCELLING? +> +>> +> +>> Actually I thought that would be the case already (in fact CANCELLING is +> +>> internal only; the outside world sees it as "active" in query-migrate). +> +>> +> +>> Lei, what is the runstate? (That is, why did cont succeed at all)? +> +> +> +> I suspect it's RUN_STATE_FINISH_MIGRATE - we set that before we do the +> +device +> +> save, and that's what we get at the end of a migrate and it's legal to +> +restart +> +> from there. +> +> +Yeah, but I think we get there at the end of a failed migrate only. So +> +perhaps we can introduce a new state RUN_STATE_FAILED_MIGRATE +I think we do not need to introduce a new state here. If we hit 'cont' and +the run state is RUN_STATE_FINISH_MIGRATE, we could assume that +migration failed because 'RUN_STATE_FINISH_MIGRATE' only exists on +source side, means we are finishing migration, a 'cont' at the meantime +indicates that we are rolling back, otherwise source side should be +destroyed. + + +> +and forbid +> +"cont" from finish-migrate (only allow it from failed-migrate)? +> +The problem of forbid 'cont' here is that it will result in a failed +migration and the source +side will remain paused. We actually expect a usable guest when rollback. +Is there a way to kill migration thread when we're under main thread, if +there is, we +could do the following to solve this problem: +1. 'cont' received during runstate RUN_STATE_FINISH_MIGRATE +2. kill migration thread +3. vm_start() + +But this only solves 'cont' problem. As Dave said before, other things could +happen during the small windows while we are finishing migration, that's +what I was worried about... + + +> +Paolo +> +> +>> Paolo +> +>> +> +>>> I'd really love to see the 'run_on_cpu' being more careful about the +> +BQL; +> +>>> we really need all of the rest of the devices to stay quiesced at +> +times. +> +>> +> +>> That's not really possible, because of how condition variables work. :( +> +> +> +> *Really* we need to find a solution to that - there's probably lots of +> +> other things that can spring up in that small window other than the +> +> 'cont'. +> +> +> +> Dave +> +> +> +> -- +> +> Dr. David Alan Gilbert / address@hidden / Manchester, UK +> +> +> +> + +* Paolo Bonzini (address@hidden) wrote: +> +> +> +On 03/03/2017 14:26, Dr. David Alan Gilbert wrote: +> +> * Paolo Bonzini (address@hidden) wrote: +> +>> +> +>> +> +>> On 03/03/2017 14:11, Dr. David Alan Gilbert wrote: +> +>>> * Paolo Bonzini (address@hidden) wrote: +> +>>>> +> +>>>> +> +>>>> On 03/03/2017 13:00, Dr. David Alan Gilbert wrote: +> +>>>>> Ouch that's pretty nasty; I remember Paolo explaining to me a while ago +> +>>>>> that +> +>>>>> their were times when run_on_cpu would have to drop the BQL and I +> +>>>>> worried about it, +> +>>>>> but this is the 1st time I've seen an error due to it. +> +>>>>> +> +>>>>> Do you know what the migration state was at that point? Was it +> +>>>>> MIGRATION_STATUS_CANCELLING? +> +>>>>> I'm thinking perhaps we should stop 'cont' from continuing while +> +>>>>> migration is in +> +>>>>> MIGRATION_STATUS_CANCELLING. Do we send an event when we hit CANCELLED +> +>>>>> - so that +> +>>>>> perhaps libvirt could avoid sending the 'cont' until then? +> +>>>> +> +>>>> No, there's no event, though I thought libvirt would poll until +> +>>>> "query-migrate" returns the cancelled state. Of course that is a small +> +>>>> consolation, because a segfault is unacceptable. +> +>>> +> +>>> I think you might get an event if you set the new migrate capability +> +>>> called +> +>>> 'events' on! +> +>>> +> +>>> void migrate_set_state(int *state, int old_state, int new_state) +> +>>> { +> +>>> if (atomic_cmpxchg(state, old_state, new_state) == old_state) { +> +>>> trace_migrate_set_state(new_state); +> +>>> migrate_generate_event(new_state); +> +>>> } +> +>>> } +> +>>> +> +>>> static void migrate_generate_event(int new_state) +> +>>> { +> +>>> if (migrate_use_events()) { +> +>>> qapi_event_send_migration(new_state, &error_abort); +> +>>> } +> +>>> } +> +>>> +> +>>> That event feature went in sometime after 2.3.0. +> +>>> +> +>>>> One possibility is to suspend the monitor in qmp_migrate_cancel and +> +>>>> resume it (with add_migration_state_change_notifier) when we hit the +> +>>>> CANCELLED state. I'm not sure what the latency would be between the end +> +>>>> of migrate_fd_cancel and finally reaching CANCELLED. +> +>>> +> +>>> I don't like suspending monitors; it can potentially take quite a +> +>>> significant +> +>>> time to do a cancel. +> +>>> How about making 'cont' fail if we're in CANCELLING? +> +>> +> +>> Actually I thought that would be the case already (in fact CANCELLING is +> +>> internal only; the outside world sees it as "active" in query-migrate). +> +>> +> +>> Lei, what is the runstate? (That is, why did cont succeed at all)? +> +> +> +> I suspect it's RUN_STATE_FINISH_MIGRATE - we set that before we do the +> +> device +> +> save, and that's what we get at the end of a migrate and it's legal to +> +> restart +> +> from there. +> +> +Yeah, but I think we get there at the end of a failed migrate only. So +> +perhaps we can introduce a new state RUN_STATE_FAILED_MIGRATE and forbid +> +"cont" from finish-migrate (only allow it from failed-migrate)? +OK, I was wrong in my previous statement; we actually go +FINISH_MIGRATE->POSTMIGRATE +so no new state is needed; you shouldn't be restarting the cpu in +FINISH_MIGRATE. + +My preference is to get libvirt to wait for the transition to POSTMIGRATE before +it issues the 'cont'. I'd rather not block the monitor with 'cont' but I'm +not sure how we'd cleanly make cont fail without breaking existing libvirts +that usually don't hit this race. (cc'ing in Jiri). + +Dave + +> +Paolo +> +> +>> Paolo +> +>> +> +>>> I'd really love to see the 'run_on_cpu' being more careful about the BQL; +> +>>> we really need all of the rest of the devices to stay quiesced at times. +> +>> +> +>> That's not really possible, because of how condition variables work. :( +> +> +> +> *Really* we need to find a solution to that - there's probably lots of +> +> other things that can spring up in that small window other than the +> +> 'cont'. +> +> +> +> Dave +> +> +> +> -- +> +> Dr. David Alan Gilbert / address@hidden / Manchester, UK +> +> +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +Hi Dave, + +On Fri, Mar 3, 2017 at 9:26 PM, Dr. David Alan Gilbert <address@hidden> +wrote: + +> +* Paolo Bonzini (address@hidden) wrote: +> +> +> +> +> +> On 03/03/2017 14:11, Dr. David Alan Gilbert wrote: +> +> > * Paolo Bonzini (address@hidden) wrote: +> +> >> +> +> >> +> +> >> On 03/03/2017 13:00, Dr. David Alan Gilbert wrote: +> +... +> +> > That event feature went in sometime after 2.3.0. +> +> > +> +> >> One possibility is to suspend the monitor in qmp_migrate_cancel and +> +> >> resume it (with add_migration_state_change_notifier) when we hit the +> +> >> CANCELLED state. I'm not sure what the latency would be between the +> +end +> +> >> of migrate_fd_cancel and finally reaching CANCELLED. +> +> > +> +> > I don't like suspending monitors; it can potentially take quite a +> +significant +> +> > time to do a cancel. +> +> > How about making 'cont' fail if we're in CANCELLING? +> +> +> +> Actually I thought that would be the case already (in fact CANCELLING is +> +> internal only; the outside world sees it as "active" in query-migrate). +> +> +> +> Lei, what is the runstate? (That is, why did cont succeed at all)? +> +> +I suspect it's RUN_STATE_FINISH_MIGRATE - we set that before we do the +> +device +> +It is RUN_STATE_FINISH_MIGRATE. + + +> +save, and that's what we get at the end of a migrate and it's legal to +> +restart +> +from there. +> +> +> Paolo +> +> +> +> > I'd really love to see the 'run_on_cpu' being more careful about the +> +BQL; +> +> > we really need all of the rest of the devices to stay quiesced at +> +times. +> +> +> +> That's not really possible, because of how condition variables work. :( +> +> +*Really* we need to find a solution to that - there's probably lots of +> +other things that can spring up in that small window other than the +> +'cont'. +> +This is what I was worry about. Not only sync_cpu_state() will call +run_on_cpu() +but also vm_stop_force_state() will, both of them did hit the small windows +in our +test. + + +> +> +Dave +> +> +-- +> +Dr. David Alan Gilbert / address@hidden / Manchester, UK +> +> + diff --git a/results/classifier/zero-shot/108/none/1623 b/results/classifier/zero-shot/108/none/1623 new file mode 100644 index 000000000..7cf5fc8cd --- /dev/null +++ b/results/classifier/zero-shot/108/none/1623 @@ -0,0 +1,24 @@ +graphic: 0.247 +device: 0.222 +semantic: 0.109 +socket: 0.060 +boot: 0.037 +other: 0.036 +debug: 0.033 +PID: 0.030 +network: 0.027 +performance: 0.026 +permissions: 0.025 +vnc: 0.016 +files: 0.013 +KVM: 0.002 + +vec_lde and vec_expte semi-randomly produce the wrong results +Description of problem: +I found that while implementing the Altivec support for the rust [stdarch](https://github.com/rust-lang/stdarch). +Steps to reproduce: +1. Install rust nightly (e.g. using https://rustup.rs/) +2. `git clone https://github.com/rust-lang/stdarch` +3. You need to either cross compile or compile and run the tests for `crates/core_arch`. +Additional information: +Both `valgrind` and running on power9 produce the correct results diff --git a/results/classifier/zero-shot/108/none/1626972 b/results/classifier/zero-shot/108/none/1626972 new file mode 100644 index 000000000..3fb7f7e2a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1626972 @@ -0,0 +1,3871 @@ +KVM: 0.571 +vnc: 0.495 +other: 0.474 +device: 0.260 +permissions: 0.248 +network: 0.230 +PID: 0.229 +debug: 0.228 +semantic: 0.216 +graphic: 0.214 +boot: 0.210 +performance: 0.201 +socket: 0.200 +files: 0.147 + +QEMU memfd_create fallback mechanism change for security drivers + +And, when libvirt starts using apparmor, and creating apparmor profiles for every virtual machine created in the compute nodes, mitaka qemu (2.5 - and upstream also) uses a fallback mechanism for creating shared memory for live-migrations. This fall back mechanism, on kernels 3.13 - that don't have memfd_create() system-call, try to create files on /tmp/ directory and fails.. causing live-migration not to work. + +Trusty with kernel 3.13 + Mitaka with qemu 2.5 + apparmor capability = can't live migrate. + +From qemu 2.5, logic is on : + +void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, int *fd) +{ + if (memfd_create)... ### only works with HWE kernels + + else ### 3.13 kernels, gets blocked by apparmor + tmpdir = g_get_tmp_dir + ... + mfd = mkstemp(fname) +} + +And you can see the errors: + +From the host trying to send the virtual machine: + +2016-08-15 16:36:26.160 1974 ERROR nova.virt.libvirt.driver [req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 133ebc3585c041aebaead8c062cd6511 - - -] [instance: 2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Migration operation has aborted +2016-08-15 16:36:26.248 1974 ERROR nova.virt.libvirt.driver [req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 133ebc3585c041aebaead8c062cd6511 - - -] [instance: 2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Live Migration failure: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory + +From the host trying to receive the virtual machine: + +Aug 15 16:36:19 tkcompute01 kernel: [ 1194.356794] type=1400 audit(1471289779.791:72): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" pid=12565 comm="apparmor_parser" +Aug 15 16:36:19 tkcompute01 kernel: [ 1194.357048] type=1400 audit(1471289779.791:73): apparmor="STATUS" operation="profile_load" profile="unconfined" name="qemu_bridge_helper" pid=12565 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.877027] type=1400 audit(1471289780.311:74): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" pid=12613 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.904407] type=1400 audit(1471289780.343:75): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="qemu_bridge_helper" pid=12613 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.973064] type=1400 audit(1471289780.407:76): apparmor="DENIED" operation="mknod" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/memfd-tNpKSj" pid=12625 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 ouid=107 +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979871] type=1400 audit(1471289780.411:77): apparmor="DENIED" operation="open" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/" pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979881] type=1400 audit(1471289780.411:78): apparmor="DENIED" operation="open" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/var/tmp/" pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 + +When leaving libvirt without apparmor capabilities (thus not confining virtual machines on compute nodes, the live migration works as expected, so, clearly, apparmor is stepping into the live migration). I'm sure that virtual machines have to be confined and that this isn't the desired behaviour... + +Related: https://bugs.launchpad.net/nova/+bug/1613423 + +I came up with this patch for QEMU: + +http://paste.ubuntu.com/23217056/ + +I'm finishing libvirt patch so I can propose upstream QEMU already sure that libvirt will benefit from this change. Right after I'll propose libvirt upstream patch (changing vert-aa-helper logic). + +And later: + +Improved it a little bit: http://paste.ubuntu.com/23217333/ + +And fixed it: + +http://paste.ubuntu.com/23219599/ +(Probable the version to be suggested to upstream) + +Fixed it according to checkpatch.pl as stated in http://wiki.qemu.org/Contribute/SubmitAPatch. + +http://paste.ubuntu.com/23220104/ + +Will submit to mailing list after testing everything. + +Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +mechanism for systems not supporting memfd_create syscall (started +being supported since 3.17). + +Backporting memfd_create might not be accepted for distros relying +on older kernels. Nowadays there is no way for security driver +to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. + +It is more appropriate to include UUID and/or VM names in the +temporary filename, allowing security driver rules to be applied +while maintaining the required unpredictability with mkstemp. + +This change will allow libvirt to know exact memfd file to be created +for vhost log AND to create appropriate security rules to allow access +per instance (instead of a opened rule like <tmpdir>/memfd-*). + +Example of apparmor deny messages with this change: + +Per VM UUID (preferred, generated automatically by libvirt): + +kernel: [26632.154856] type=1400 audit(1474945148.633:78): apparmor= +"DENIED" operation="mknod" profile="libvirt-0b96011f-0dc0-44a3-92c3- +196de2efab6d" name="/tmp/memfd-0b96011f-0dc0-44a3-92c3-196de2efab6d- +qeHrBV" pid=75161 comm="qemu-system-x86" requested_mask="c" denied_ +mask="c" fsuid=107 ouid=107 + +Per VM name (if no UUID is specified): + +kernel: [26447.505653] type=1400 audit(1474944963.985:72): apparmor= +"DENIED" operation="mknod" profile="libvirt-00000000-0000-0000-0000- +000000000000" name="/tmp/memfd-instance-teste-osYpHh" pid=74648 +comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 +ouid=107 + +Signed-off-by: Rafael David Tinoco <email address hidden> +--- + util/memfd.c | 26 +++++++++++++++++++++++++- + 1 file changed, 25 insertions(+), 1 deletion(-) + +diff --git a/util/memfd.c b/util/memfd.c +index 4571d1a..4b715ac 100644 +--- a/util/memfd.c ++++ b/util/memfd.c +@@ -30,6 +30,9 @@ + #include <glib/gprintf.h> + + #include "qemu/memfd.h" ++#include "qmp-commands.h" ++#include "qemu-common.h" ++#include "sysemu/sysemu.h" + + #ifdef CONFIG_MEMFD + #include <sys/memfd.h> +@@ -94,11 +97,32 @@ void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, + return NULL; + } + } else { ++ int ret = 0; + const char *tmpdir = g_get_tmp_dir(); ++ UuidInfo *uinfo; ++ NameInfo *ninfo; + gchar *fname; + +- fname = g_strdup_printf("%s/memfd-XXXXXX", tmpdir); ++ uinfo = qmp_query_uuid(NULL); ++ ++ ret = strcmp(uinfo->UUID, UUID_NONE); ++ if (ret == 0) { ++ ninfo = qmp_query_name(NULL); ++ if (ninfo->has_name) { ++ fname = g_strdup_printf("%s/memfd-%s-XXXXXX", tmpdir, ++ ninfo->name); ++ } else { ++ fname = g_strdup_printf("%s/memfd-XXXXXX", tmpdir); ++ } ++ qapi_free_NameInfo(ninfo); ++ } else { ++ fname = g_strdup_printf("%s/memfd-%s-XXXXXX", tmpdir, ++ uinfo->UUID); ++ } ++ + mfd = mkstemp(fname); ++ ++ qapi_free_UuidInfo(uinfo); + unlink(fname); + g_free(fname); + +-- +2.9.3 + + + +Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +mechanism for systems not supporting memfd_create syscall (started +being supported since 3.17). + +Backporting memfd_create might not be accepted for distros relying +on older kernels. Nowadays there is no way for security driver +to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. + +It is more appropriate to include UUID and/or VM names in the +temporary filename, allowing security driver rules to be applied +while maintaining the required unpredictability with mkstemp. + +This change will allow libvirt to know exact memfd file to be created +for vhost log AND to create appropriate security rules to allow access +per instance (instead of a opened rule like <tmpdir>/memfd-*). + +Example of apparmor deny messages with this change: + +Per VM UUID (preferred, generated automatically by libvirt): + +kernel: [26632.154856] type=1400 audit(1474945148.633:78): apparmor= +"DENIED" operation="mknod" profile="libvirt-0b96011f-0dc0-44a3-92c3- +196de2efab6d" name="/tmp/memfd-0b96011f-0dc0-44a3-92c3-196de2efab6d- +qeHrBV" pid=75161 comm="qemu-system-x86" requested_mask="c" denied_ +mask="c" fsuid=107 ouid=107 + +Per VM name (if no UUID is specified): + +kernel: [26447.505653] type=1400 audit(1474944963.985:72): apparmor= +"DENIED" operation="mknod" profile="libvirt-00000000-0000-0000-0000- +000000000000" name="/tmp/memfd-instance-teste-osYpHh" pid=74648 +comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 +ouid=107 + +Signed-off-by: Rafael David Tinoco <email address hidden> +--- + util/memfd.c | 26 +++++++++++++++++++++++++- + 1 file changed, 25 insertions(+), 1 deletion(-) + +diff --git a/util/memfd.c b/util/memfd.c +index 4571d1a..4b715ac 100644 +--- a/util/memfd.c ++++ b/util/memfd.c +@@ -30,6 +30,9 @@ + #include <glib/gprintf.h> + + #include "qemu/memfd.h" ++#include "qmp-commands.h" ++#include "qemu-common.h" ++#include "sysemu/sysemu.h" + + #ifdef CONFIG_MEMFD + #include <sys/memfd.h> +@@ -94,11 +97,32 @@ void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, + return NULL; + } + } else { ++ int ret = 0; + const char *tmpdir = g_get_tmp_dir(); ++ UuidInfo *uinfo; ++ NameInfo *ninfo; + gchar *fname; + +- fname = g_strdup_printf("%s/memfd-XXXXXX", tmpdir); ++ uinfo = qmp_query_uuid(NULL); ++ ++ ret = strcmp(uinfo->UUID, UUID_NONE); ++ if (ret == 0) { ++ ninfo = qmp_query_name(NULL); ++ if (ninfo->has_name) { ++ fname = g_strdup_printf("%s/memfd-%s-XXXXXX", tmpdir, ++ ninfo->name); ++ } else { ++ fname = g_strdup_printf("%s/memfd-XXXXXX", tmpdir); ++ } ++ qapi_free_NameInfo(ninfo); ++ } else { ++ fname = g_strdup_printf("%s/memfd-%s-XXXXXX", tmpdir, ++ uinfo->UUID); ++ } ++ + mfd = mkstemp(fname); ++ ++ qapi_free_UuidInfo(uinfo); + unlink(fname); + g_free(fname); + +-- +2.9.3 + + + +I'll follow to see if patch was accepted upstream: + +https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06191.html +https://<email address hidden>/msg400892.html + +On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +> mechanism for systems not supporting memfd_create syscall (started +> being supported since 3.17). + +This is really dubious code in general and IMHO should just +be reverted. + +We have a golden rule that any time QEMU needs to be able to +create a file on disk, then the path should be explicitly +provided as a command line argument so that mgmt apps can +control the location used. + +> Backporting memfd_create might not be accepted for distros relying +> on older kernels. Nowadays there is no way for security driver +> to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> +> It is more appropriate to include UUID and/or VM names in the +> temporary filename, allowing security driver rules to be applied +> while maintaining the required unpredictability with mkstemp. + +We should not have QEMU creating unpredictabile filenames in the +first place - any filenames should be determined by libvirt +explicitly. + +> This change will allow libvirt to know exact memfd file to be created +> for vhost log AND to create appropriate security rules to allow access +> per instance (instead of a opened rule like <tmpdir>/memfd-*). + +Even with this change it is bad - we don't want driver backends +creating arbitrary files in the shared /tmp directory. + + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| +|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| + + + +> On Sep 27, 2016, at 05:36, Daniel P. Berrange <email address hidden> wrote: +> +> On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +>> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +>> mechanism for systems not supporting memfd_create syscall (started +>> being supported since 3.17). +> +> This is really dubious code in general and IMHO should just +> be reverted. + +There are numerous people relying on older kernels in openstack +deployments - sometimes with specific drivers (ovswitch, dpdk, +infiniband) holding kernel upgrades - but still in need of upgrading +userland (e.g. newer releases). Having a fallback mechanism seems +appropriate for those cases. + +> +> We have a golden rule that any time QEMU needs to be able to +> create a file on disk, then the path should be explicitly +> provided as a command line argument so that mgmt apps can +> control the location used. +> +>> Backporting memfd_create might not be accepted for distros relying +>> on older kernels. Nowadays there is no way for security driver +>> to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +>> +>> It is more appropriate to include UUID and/or VM names in the +>> temporary filename, allowing security driver rules to be applied +>> while maintaining the required unpredictability with mkstemp. +> +> We should not have QEMU creating unpredictabile filenames in the +> first place - any filenames should be determined by libvirt +> explicitly. + +Note that the filename, per se, is not as important as other files, +since qemu won't provide it for being accessed by external programs, and, +deletes the file, while keeping the descriptor, right after its creation +(due to its nature, that is probably why it was created in /tmp). + +Having libvirt to define a filename that would not be used for recent +kernels (> 3.17) and would exist for a fraction of second doesn't seem +right to me. + +> +>> This change will allow libvirt to know exact memfd file to be created +>> for vhost log AND to create appropriate security rules to allow access +>> per instance (instead of a opened rule like <tmpdir>/memfd-*). +> +> Even with this change it is bad - we don't want driver backends +> creating arbitrary files in the shared /tmp directory. + +On the other hand, if we are creating a tmp file, like I said, I see +benefit on having unpredictability (mkstemp), but providing predictable +parts to allow security driver to apply rules per instance basis +(/tmp/memfd-UUID*, /tmp/memfd-VMname*). + +Looking forward to a decision so I can backport correct behaviour +(with or without memfd file). + +Thank you! + +Best Regards, +Rafael + + + +Hello! + +> On Sep 27, 2016, at 08:13, Marc-André Lureau <email address hidden> wrote: +> +>> Note that the filename, per se, is not as important as other files, +>> since qemu won't provide it for being accessed by external programs, and, +>> deletes the file, while keeping the descriptor, right after its creation +>> (due to its nature, that is probably why it was created in /tmp). +>> +>> Having libvirt to define a filename that would not be used for recent +>> kernels (> 3.17) and would exist for a fraction of second doesn't seem +>> right to me. +>> +> +> There are other parts of qemu that rely on creating temporary files, and this seems to lack a bit of uniformity. Would it make sense to define a place where qemu could create those? Or setting TMPDIR should help too. Could libvirt set a per-vm TMPDIR with appropriate security rules? + +You got a point. With a per-vm TMPDIR we don't have to care about filenames in future for the security driver, while still securing them per-instance base. I'll come back to you! + +Thank you! + +On Tue, Sep 27, 2016 at 11:01:10AM -0000, Rafael David Tinoco wrote: +> > On Sep 27, 2016, at 05:36, Daniel P. Berrange <email address hidden> wrote: +> > +> > On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +> >> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +> >> mechanism for systems not supporting memfd_create syscall (started +> >> being supported since 3.17). +> > +> > This is really dubious code in general and IMHO should just +> > be reverted. +> +> There are numerous people relying on older kernels in openstack +> deployments - sometimes with specific drivers (ovswitch, dpdk, +> infiniband) holding kernel upgrades - but still in need of upgrading +> userland (e.g. newer releases). Having a fallback mechanism seems +> appropriate for those cases. + +I'm not against some kind of fallback - just about the way it +silently creates files in /tmp. + +> +> Note that the filename, per se, is not as important as other files, +> since qemu won't provide it for being accessed by external programs, and, +> deletes the file, while keeping the descriptor, right after its creation +> (due to its nature, that is probably why it was created in /tmp). + +If it doesn't shared with other processes, and is deleted immediately, +why does the file need to be on disk at all ? + + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| +|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| + + +On Tue, Sep 27, 2016 at 07:13:55AM -0400, Marc-André Lureau wrote: +> Hi +> +> ----- Original Message ----- +> > +> > > On Sep 27, 2016, at 05:36, Daniel P. Berrange <email address hidden> wrote: +> > > +> > > On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +> > > We should not have QEMU creating unpredictabile filenames in the +> > > first place - any filenames should be determined by libvirt +> > > explicitly. +> > +> > Note that the filename, per se, is not as important as other files, +> > since qemu won't provide it for being accessed by external programs, and, +> > deletes the file, while keeping the descriptor, right after its creation +> > (due to its nature, that is probably why it was created in /tmp). +> > +> > Having libvirt to define a filename that would not be used for recent +> > kernels (> 3.17) and would exist for a fraction of second doesn't seem +> > right to me. +> > +> +> There are other parts of qemu that rely on creating temporary files, and +> this seems to lack a bit of uniformity. Would it make sense to define a +> place where qemu could create those? Or setting TMPDIR should help too. +> Could libvirt set a per-vm TMPDIR with appropriate security rules? + +The other places that use mkstemp are block for snapshot=on, which +libvirt does not support as we want control over the filename. This +needs fixing by allowing a filename to be given. The qemu sockets code +uses it for auto-creating a UNIX domain socket path, but again libvirt +doesn't support that usage. The exec.c file uses it, but that honours +an explicit directory path provided on the command line. So this memfd +code really is the first place which is causing a real + +Just setting TMPDIR per VM doesn't magically solve all these cases as +it isn't reasonable to assume that all these files should be in the +same location. Certainly block snapshot file will be somewhere different +from others, due to its size. + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| +|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| + + +Sorry, I was only able to come back to this today. + +> On Sep 27, 2016, at 09:18, Daniel Berrange <email address hidden> wrote: +> +>> There are numerous people relying on older kernels in openstack +>> deployments - sometimes with specific drivers (ovswitch, dpdk, +>> infiniband) holding kernel upgrades - but still in need of upgrading +>> userland (e.g. newer releases). Having a fallback mechanism seems +>> appropriate for those cases. +> +> I'm not against some kind of fallback - just about the way it +> silently creates files in /tmp. +> + +That is why memfd_create is used here I suppose: To allow anonymous-backed-pages to have a descriptor and to be sealed. When falling back this mechanism I don't see any other way other than creating a temporary file. Of course one way would be something like: + +http://paste.ubuntu.com/23270379/ + +But this is pretty much the same, just solving the "where to place the temporary file" (non configurable for this usage). + +>> +>> Note that the filename, per se, is not as important as other files, +>> since qemu won't provide it for being accessed by external programs, and, +>> deletes the file, while keeping the descriptor, right after its creation +>> (due to its nature, that is probably why it was created in /tmp). +> +> If it doesn't shared with other processes, and is deleted immediately, +> why does the file need to be on disk at all ? + +Well, it unlinks the file but the references are still there while the descriptor isn't closed by this process, or by the one that receives the descriptor (that is why is the "unlink" so early). + +If you check vhost_dev_log_resize(), it gets *possible* new vhost log (if a new size is given) and informs the vhost dev driver about the new log base (vhost_ops->vhost_set_log_base). + +For vhost_user, this means that the file descriptors for vhost logs are likely going to be passed to vhost backend (fds[] in vhost_user_set_log_base). This is just one example, not sure about others. + +Probably the best approach here, like what Marc-André said, is to create some sort of TMPDIR, set by libvirt perhaps ? + +> +> Regards, +> Daniel + + + +Hello Marc, + +> On Sep 27, 2016, at 08:13, Marc-André Lureau <email address hidden> wrote: +> +>>> On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +>>> We should not have QEMU creating unpredictabile filenames in the +>>> first place - any filenames should be determined by libvirt +>>> explicitly. +>> +>> Note that the filename, per se, is not as important as other files, +>> since qemu won't provide it for being accessed by external programs, and, +>> deletes the file, while keeping the descriptor, right after its creation +>> (due to its nature, that is probably why it was created in /tmp). +>> +>> Having libvirt to define a filename that would not be used for recent +>> kernels (> 3.17) and would exist for a fraction of second doesn't seem +>> right to me. +>> +> +> There are other parts of qemu that rely on creating temporary files, and this seems to lack a bit of uniformity. Would it make sense to define a place where qemu could create those? Or setting TMPDIR should help too. Could libvirt set a per-vm TMPDIR with appropriate security rules? + +Best move I can see. Only problem is that if we do that, we would have to create a fallback mechanism for when TMPDIR is not set. It would go back to /tmp ? + +In my particular case (for 1 vhost log file): + +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:5c:10:f2,bus=pci.0,addr=0x3 + +I could have something similar to: + +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:5c:10:f2,bus=pci.0,addr=0x3,vhostpath=/var/lib/XXXX/YYYY/ + +and put mkstemp() files (one per vhost device) in there. + +Even so, what to do when "vhostpath" is not informed ? + +I'm worried that, right now there are security drivers either blocking the live migration entirely or allowing all instances to be able to read /tmp/memfd-XXXX. + +Don't you think we could push the first patch until we come up with a better approach for the tmp (and default tmp) files & directories ? The patch is not worse than what was committed already. + +Tks + +Rafael + + + + +On Mon, Oct 03, 2016 at 03:41:10PM -0000, Rafael David Tinoco wrote: +> Sorry, I was only able to come back to this today. +> +> > On Sep 27, 2016, at 09:18, Daniel Berrange <email address hidden> wrote: +> > +> >> There are numerous people relying on older kernels in openstack +> >> deployments - sometimes with specific drivers (ovswitch, dpdk, +> >> infiniband) holding kernel upgrades - but still in need of upgrading +> >> userland (e.g. newer releases). Having a fallback mechanism seems +> >> appropriate for those cases. +> > +> > I'm not against some kind of fallback - just about the way it +> > silently creates files in /tmp. +> > +> +> That is why memfd_create is used here I suppose: To allow anonymous- +> backed-pages to have a descriptor and to be sealed. When falling back +> this mechanism I don't see any other way other than creating a temporary +> file. Of course one way would be something like: +> +> http://paste.ubuntu.com/23270379/ +> +> But this is pretty much the same, just solving the "where to place the +> temporary file" (non configurable for this usage). +> +> >> +> >> Note that the filename, per se, is not as important as other files, +> >> since qemu won't provide it for being accessed by external programs, and, +> >> deletes the file, while keeping the descriptor, right after its creation +> >> (due to its nature, that is probably why it was created in /tmp). +> > +> > If it doesn't shared with other processes, and is deleted immediately, +> > why does the file need to be on disk at all ? +> +> Well, it unlinks the file but the references are still there while the +> descriptor isn't closed by this process, or by the one that receives the +> descriptor (that is why is the "unlink" so early). +> +> If you check vhost_dev_log_resize(), it gets *possible* new vhost log +> (if a new size is given) and informs the vhost dev driver about the new +> log base (vhost_ops->vhost_set_log_base). +> +> For vhost_user, this means that the file descriptors for vhost logs are +> likely going to be passed to vhost backend (fds[] in +> vhost_user_set_log_base). This is just one example, not sure about +> others. +> +> Probably the best approach here, like what Marc-André said, is to create +> some sort of TMPDIR, set by libvirt perhaps ? + +So you're saying that the file descriptor here is actually getting +passed to a different process for it to use ? + +If so that means we definitely do not want this in TMPDIR. If we +create a generic file in TMPDIR, then its going to have a generic +security label. That means that the other process we're giving the +FD to is going to have to be granted permission to access this FD +and we certainly don't want to grant permission for it to access +any of QEMU's other FDs. So for the SELinux integration, we'll +need this FD to be in a specific directory, so that we can setup +policy such that the file created gets given a specific SELinux +label. We can then grant the other process access to only that +particular file, and not anything else of QEMU's. + +This makes me wonder about the memfd_create() code path too - we'll +again not want that external process to be granted access to arbitrary +FDs of QEMU's and I'm not sure of a way to get the memfd FD to have +a specific label. So I think it is possible that when using libvirt +we'll want the ability to tell QEMU to *always* use an explicit file +in a path libvirt specifies, and never use memfd even if available. + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| + + +Hello Daniel, + +> On Oct 03, 2016, at 14:55, Daniel P. Berrange <email address hidden> wrote: +> +>> Well, it unlinks the file but the references are still there while the +>> descriptor isn't closed by this process, or by the one that receives the +>> descriptor (that is why is the "unlink" so early). +>> +>> If you check vhost_dev_log_resize(), it gets *possible* new vhost log +>> (if a new size is given) and informs the vhost dev driver about the new +>> log base (vhost_ops->vhost_set_log_base). +>> +>> For vhost_user, this means that the file descriptors for vhost logs are +>> likely going to be passed to vhost backend (fds[] in +>> vhost_user_set_log_base). This is just one example, not sure about +>> others. +>> +>> Probably the best approach here, like what Marc-André said, is to create +>> some sort of TMPDIR, set by libvirt perhaps ? +> +> So you're saying that the file descriptor here is actually getting +> passed to a different process for it to use ? +> +> If so that means we definitely do not want this in TMPDIR. If we +> create a generic file in TMPDIR, then its going to have a generic +> security label. That means that the other process we're giving the +> FD to is going to have to be granted permission to access this FD +> and we certainly don't want to grant permission for it to access +> any of QEMU's other FDs. So for the SELinux integration, we'll +> need this FD to be in a specific directory, so that we can setup +> policy such that the file created gets given a specific SELinux +> label. We can then grant the other process access to only that +> particular file, and not anything else of QEMU's. +> +> This makes me wonder about the memfd_create() code path too - we'll +> again not want that external process to be granted access to arbitrary +> FDs of QEMU's and I'm not sure of a way to get the memfd FD to have +> a specific label. So I think it is possible that when using libvirt +> we'll want the ability to tell QEMU to *always* use an explicit file +> in a path libvirt specifies, and never use memfd even if available. + +Check this execution path: + +(vhost_vsock_device_realize) + vhost_dev_init + vhost_commit + |- vhost_get_log_size + |... + |- vhost_dev_log_resize + +(vhost_dev_log_resize): + vhost_log_get -> here if the size is bigger, a new log is created + dev->vhost_ops->vhost_set_log_base() -> kernel or user vhost driver + vhost_log_put() + +---- + +So, + +* In case of the kernel mode, this is just a: + +vhost in kernel mode = vhost_kernel_set_log_base +return vhost_kernel_call(dev, VHOST_SET_LOG_BASE, &base); + +which makes an ioctl to dev->opaque file descriptor to set a new vhost log base. + +* But in the case of user mode: + +vhost in user mode = vhost_user_set_log_base + +which gets the log file descriptor (log->fd) and gives to vhost_user_write. vhost_user_write will do a qemu_chr_fe_set_msgfds passing the log file descriptors for the backend vhost driver (CharDriverState). + +If I'm reading this right.. if the backend driver is: + +static int tcp_set_msgfds(CharDriverState *chr, int *fds, int num) + +it would check for: + +!qio_channel_has_feature(s->ioc, QIO_CHANNEL_FEATURE_FD_PASS)) { + +and configure s->write_msgfds. This would be sent in: + +static int tcp_chr_write(CharDriverState *chr, const uint8_t *buf, int len) + +with "io_channel_send_full" + "qio_channel_writev_full + io_writev from QIOChannelClass. + +---- + +https://www.berrange.com/posts/2016/08/16/ + +This, from your blog, probably confirms this behaviour: + +"The migration code supports a number of different protocols besides just “tcp:“. In particular it allows an “fd:” protocol to tell QEMU to use a passed-in file descriptor, and an “exec:” protocol to tell QEMU to launch an external command to tunnel the connection. It is desirable to be able to use TLS with these protocols too, but when using TLS the client QEMU needs to know the hostname of the target QEMU in order to correctly validate the x509 certificate it receives. Thus, a second “tls-hostname” parameter was added to allow QEMU to be informed of the hostname to use for x509 certificate validation when using a non-tcp migration protocol. This can be set on the source QEMU prior to starting the migration using the “migrate_set_str_parameter” monitor command" + +=) + +Yes, definitely. Check this: + +/** + * @qemu_chr_fe_set_msgfds: + * + * For backends capable of fd passing, set an array of fds to be passed with + * the next send operation. + * A subsequent call to this function before calling a write function will + * result in overwriting the fd array with the new value without being send. + * Upon writing the message the fd array is freed. + * + * Returns: -1 if fd passing isn't supported. + */ +int qemu_chr_fe_set_msgfds(CharDriverState *s, int *fds, int num); + +---- + +So, at least for vhost_dev_log_resize, this "interface" is being implemented: + +vhost_user_set_log_base -> VhostUserMsg = VHOST_USER_SET_LOG_BASE + +vhost_user_write(with the VHOST_USER_GET_LOG_BASE message): + +- configures the file descriptors(... , fds, fd_num) + qemu_chr_fe_set_msgfds + +- writes them down the char driver + qemu_chr_fe_write_all + +> On Oct 03, 2016, at 15:46, Rafael David Tinoco <email address hidden> wrote: +> +>> So you're saying that the file descriptor here is actually getting +>> passed to a different process for it to use ? + + + +On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> Yes, definitely. Check this: + +[snip] + +So in that case, I think we must add ability to specify an explicit path +that apps can use *regardles* of whether memfd support exists or not. + +> > On Oct 03, 2016, at 15:46, Rafael David Tinoco <email address hidden> wrote: +> > +> >> So you're saying that the file descriptor here is actually getting +> >> passed to a different process for it to use ? +> + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| + + +Let me work on it. I'll get back soon. + +Tks Daniel. + +> On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> wrote: +> +> On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +>> Yes, definitely. Check this: +> +> [snip] +> +> So in that case, I think we must add ability to specify an explicit path +> that apps can use *regardles* of whether memfd support exists or not. +> +>>> On Oct 03, 2016, at 15:46, Rafael David Tinoco <email address hidden> wrote: +>>> +>>>> So you're saying that the file descriptor here is actually getting +>>>> passed to a different process for it to use ? + + + +Hi Rafael, Daniel, + +On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +<email address hidden>> wrote: + +> Let me work on it. I'll get back soon. +> +> +thanks for working on it, before that I have a few questions: + +Tks Daniel. +> +> > On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> +> wrote: +> > +> > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> >> Yes, definitely. Check this: +> > +> > [snip] +> > +> > So in that case, I think we must add ability to specify an explicit path +> > that apps can use *regardles* of whether memfd support exists or not. +> + +How will this path be used? Is it going to be global to qemu for various +use (kinda like $TMP), or per-device, or for memfd fallback only? Should +the path pre-exist? (I suppose, if not, qemu should clean it up when +leaving) + +> +> >>> On Oct 03, 2016, at 15:46, Rafael David Tinoco < +> <email address hidden>> wrote: +> >>> +> >>>> So you're saying that the file descriptor here is actually getting +> >>>> passed to a different process for it to use ? +> +> +> -- +Marc-André Lureau + + +On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-André Lureau wrote: +> Hi Rafael, Daniel, +> +> On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +> <email address hidden>> wrote: +> +> > Let me work on it. I'll get back soon. +> > +> > +> thanks for working on it, before that I have a few questions: +> +> Tks Daniel. +> > +> > > On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> +> > wrote: +> > > +> > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> > >> Yes, definitely. Check this: +> > > +> > > [snip] +> > > +> > > So in that case, I think we must add ability to specify an explicit path +> > > that apps can use *regardles* of whether memfd support exists or not. +> > +> +> How will this path be used? Is it going to be global to qemu for various +> use (kinda like $TMP), or per-device, or for memfd fallback only? Should +> the path pre-exist? (I suppose, if not, qemu should clean it up when +> leaving) + +I'd expect it to be an option set against the vhost user backend, since +that's the thing using this. + +If other things have similar usage needs wrt memfd in future, they would +also need similar path config option. + + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| + + +Hi + +On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange <email address hidden> +wrote: + +> On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-André Lureau wrote: +> > Hi Rafael, Daniel, +> > +> > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +> > <email address hidden>> wrote: +> > +> > > Let me work on it. I'll get back soon. +> > > +> > > +> > thanks for working on it, before that I have a few questions: +> > +> > Tks Daniel. +> > > +> > > > On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> +> > > wrote: +> > > > +> > > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> > > >> Yes, definitely. Check this: +> > > > +> > > > [snip] +> > > > +> > > > So in that case, I think we must add ability to specify an explicit +> path +> > > > that apps can use *regardles* of whether memfd support exists or not. +> > > +> > +> > How will this path be used? Is it going to be global to qemu for various +> > use (kinda like $TMP), or per-device, or for memfd fallback only? Should +> > the path pre-exist? (I suppose, if not, qemu should clean it up when +> > leaving) +> +> I'd expect it to be an option set against the vhost user backend, since +> that's the thing using this. +> +> If other things have similar usage needs wrt memfd in future, they would +> also need similar path config option. +> + +The log may be shared if there are several vhost-user (stored in +vhost_log_shm global), so I think it makes more sense to have a global +config path for it, or you may end up duplicating that information per +vhost backend and having files in either of the specified paths. + + +> +> +> Regards, +> Daniel +> -- +> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ +> :| +> |: http://libvirt.org -o- http://virt-manager.org +> :| +> |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ +> :| +> +-- +Marc-André Lureau + + +On Tue, Oct 04, 2016 at 01:10:17PM +0000, Marc-André Lureau wrote: +> Hi +> +> On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange <email address hidden> +> wrote: +> +> > On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-André Lureau wrote: +> > > Hi Rafael, Daniel, +> > > +> > > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +> > > <email address hidden>> wrote: +> > > +> > > > Let me work on it. I'll get back soon. +> > > > +> > > > +> > > thanks for working on it, before that I have a few questions: +> > > +> > > Tks Daniel. +> > > > +> > > > > On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> +> > > > wrote: +> > > > > +> > > > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> > > > >> Yes, definitely. Check this: +> > > > > +> > > > > [snip] +> > > > > +> > > > > So in that case, I think we must add ability to specify an explicit +> > path +> > > > > that apps can use *regardles* of whether memfd support exists or not. +> > > > +> > > +> > > How will this path be used? Is it going to be global to qemu for various +> > > use (kinda like $TMP), or per-device, or for memfd fallback only? Should +> > > the path pre-exist? (I suppose, if not, qemu should clean it up when +> > > leaving) +> > +> > I'd expect it to be an option set against the vhost user backend, since +> > that's the thing using this. +> > +> > If other things have similar usage needs wrt memfd in future, they would +> > also need similar path config option. +> > +> +> The log may be shared if there are several vhost-user (stored in +> vhost_log_shm global), so I think it makes more sense to have a global +> config path for it, or you may end up duplicating that information per +> vhost backend and having files in either of the specified paths. + +Hmm, is there a reason why it is shared? That seems to make an assumption +that all vhost-user backends would be managed by the same external process. +While that may be the common case today, it doesn't feel like a reasonable +assumption to make long term. IOW it feels wiser to have it set per-NIC +unless I'm missing something important that means it must be shared ? + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| + + + +> On Oct 04, 2016, at 10:10, Marc-André Lureau <email address hidden> wrote: +> +> > How will this path be used? Is it going to be global to qemu for various +> > use (kinda like $TMP), or per-device, or for memfd fallback only? Should +> > the path pre-exist? (I suppose, if not, qemu should clean it up when +> > leaving) +> +> I'd expect it to be an option set against the vhost user backend, since +> that's the thing using this. +> +> If other things have similar usage needs wrt memfd in future, they would +> also need similar path config option. + +I was going for that approach. I could have something similar to: + +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:5c:10:f2,bus=pci.0,addr=0x3,vhostpath=/var/lib/XXXX/YYYY/ + +> The log may be shared if there are several vhost-user (stored in vhost_log_shm global), so I think it makes more sense to have a global config path for it, or you may end up duplicating that information per vhost backend and having files in either of the specified paths. + +But, yes, indeed the vhost_log_shm makes that approach tricky. If sharing the same log file with multiple vhost backend. Besides, tools like openstack would put all the vhost log files in the same place at the end. + +Having a global config path, forced to be specified, orelse the vhost log isn't created, like when it fails nowadays. This seems to be the right approach. + +True. + +What about having a single config parameter as a place to put all vhost logs for all drives for a single instance ? Remove the memfd implementation with all the memfd shared_memory option ? Replace it with a open+unlink+ftruncate+mmap approach only. + +This way every device would get its own log file and vhost-user backends would be able to get its file descriptors. (and, of course, allow the security drivers to do their jobs). + +>> On Oct 04, 2016, at 10:25, Daniel P. Berrange <email address hidden> wrote: +>> +>> Hmm, is there a reason why it is shared? That seems to make an assumption +>> that all vhost-user backends would be managed by the same external process. +>> While that may be the common case today, it doesn't feel like a reasonable +>> assumption to make long term. IOW it feels wiser to have it set per-NIC +>> unless I'm missing something important that means it must be shared ? +> + + + +Hi + +On Tue, Oct 4, 2016 at 5:25 PM Daniel P. Berrange <email address hidden> +wrote: + +> On Tue, Oct 04, 2016 at 01:10:17PM +0000, Marc-André Lureau wrote: +> > Hi +> > +> > On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange <email address hidden> +> > wrote: +> > +> > > On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-André Lureau wrote: +> > > > Hi Rafael, Daniel, +> > > > +> > > > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +> > > > <email address hidden>> wrote: +> > > > +> > > > > Let me work on it. I'll get back soon. +> > > > > +> > > > > +> > > > thanks for working on it, before that I have a few questions: +> > > > +> > > > Tks Daniel. +> > > > > +> > > > > > On Oct 04, 2016, at 05:36, Daniel P. Berrange < +> <email address hidden>> +> > > > > wrote: +> > > > > > +> > > > > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco +> wrote: +> > > > > >> Yes, definitely. Check this: +> > > > > > +> > > > > > [snip] +> > > > > > +> > > > > > So in that case, I think we must add ability to specify an +> explicit +> > > path +> > > > > > that apps can use *regardles* of whether memfd support exists or +> not. +> > > > > +> > > > +> > > > How will this path be used? Is it going to be global to qemu for +> various +> > > > use (kinda like $TMP), or per-device, or for memfd fallback only? +> Should +> > > > the path pre-exist? (I suppose, if not, qemu should clean it up when +> > > > leaving) +> > > +> > > I'd expect it to be an option set against the vhost user backend, since +> > > that's the thing using this. +> > > +> > > If other things have similar usage needs wrt memfd in future, they +> would +> > > also need similar path config option. +> > > +> > +> > The log may be shared if there are several vhost-user (stored in +> > vhost_log_shm global), so I think it makes more sense to have a global +> > config path for it, or you may end up duplicating that information per +> > vhost backend and having files in either of the specified paths. +> +> Hmm, is there a reason why it is shared? That seems to make an assumption +> that all vhost-user backends would be managed by the same external process. +> While that may be the common case today, it doesn't feel like a reasonable +> assumption to make long term. IOW it feels wiser to have it set per-NIC +> unless I'm missing something important that means it must be shared ? +> +> +It's a shared log, just like they share the same ram. Duplicating the log +would mostly make migration more difficult to handle and increase a bit +memory usage. + + +> Regards, +> Daniel +> -- +> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ +> :| +> |: http://libvirt.org -o- http://virt-manager.org +> :| +> |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ +> :| +> +-- +Marc-André Lureau + + +On Tue, Oct 4, 2016 at 5:34 PM Rafael David Tinoco < +<email address hidden>> wrote: + +> True. +> +> What about having a single config parameter as a place to put all vhost +> logs for all drives for a single instance ? Remove the memfd implementation +> with all the memfd shared_memory option ? Replace it with a +> open+unlink+ftruncate+mmap approach only. +> +> +I fail to see your point, memfd is superior to open+unlink and has other +advantages with sealing etc. + +Regarding shared log, see my previous reply to Daniel. + +This way every device would get its own log file and vhost-user backends +> would be able to get its file descriptors. (and, of course, allow the +> security drivers to do their jobs). +> +> >> On Oct 04, 2016, at 10:25, Daniel P. Berrange <email address hidden> +> wrote: +> >> +> >> Hmm, is there a reason why it is shared? That seems to make an +> assumption +> >> that all vhost-user backends would be managed by the same external +> process. +> >> While that may be the common case today, it doesn't feel like a +> reasonable +> >> assumption to make long term. IOW it feels wiser to have it set per-NIC +> >> unless I'm missing something important that means it must be shared ? +> > +> +> -- +Marc-André Lureau + + + +> On Oct 04, 2016, at 10:50, Marc-André Lureau <email address hidden> wrote: +> +> What about having a single config parameter as a place to put all vhost logs for all drives for a single instance ? Remove the memfd implementation with all the memfd shared_memory option ? Replace it with a open+unlink+ftruncate+mmap approach only. +> +> +> I fail to see your point, memfd is superior to open+unlink and has other advantages with sealing etc. + +I was just summarising needs based on previous statement from Daniel: + +> This makes me wonder about the memfd_create() code path too - we'll +> again not want that external process to be granted access to arbitrary +> FDs of QEMU's and I'm not sure of a way to get the memfd FD to have +> a specific label. So I think it is possible that when using libvirt +> we'll want the ability to tell QEMU to *always* use an explicit file +> in a path libvirt specifies, and never use memfd even if available. +> +> Regards, +> Daniel + + +Hello Again, finally I could get back to this, and.. + +I was finishing a patch creating the open+truncate+mmap+unlink mechanism on files specified by "vhostlog" parameter of tap devices. Patch is done, problem is that... looks like the "memfd" is only used for shared logs AND vhost-net (used for tap devices) doesn't use it. + +In the following... + +(scenario 1) + +Linux kvm01 4.8.0-22-generic #24-Ubuntu SMP Sat Oct 8 09:15:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux + +with: +-netdev tap,id=net0,vhost=on +-device virtio-net-pci,netdev=net0,id=net0,mac=52:54:00:20:c5:42,bus=pci.0,addr=0x3 + +## kvm01 + +$ ./instance.sh +qemu_memfd_check +qemu_memfd_alloc: enter +qemu_memfd_alloc: memfd_create with no sealing +qemu_memfd_alloc: memfd_create worked, truncating... +qemu_memfd_alloc: mmaping +qemu_memfd_free: enter +qemu_memfd_check: ok +vhost_dev_start: enter +vhost_log_get: enter +vhost_log_alloc: enter +vhost_log_alloc: local +vhost_log_get: not shared +vhost_log_put: enter +vhost_log_put: enter +vhost_log_put: local free + +(qemu) migrate -d tcp:kvm02:4444 +(qemu) info migrate +capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compres +Migration status: completed +total time: 14586 milliseconds +downtime: 10 milliseconds +setup: 20 milliseconds +transferred ram: 377224 kbytes +throughput: 212.02 mbps +remaining ram: 0 kbytes +total ram: 4001544 kbytes +duplicate: 908879 pages +skipped: 0 pages +normal: 92129 pages +normal bytes: 368516 kbytes +dirty sync count: 4 + +## kvm02 + +$ ./instance.sh +qemu_memfd_check +qemu_memfd_alloc: enter +qemu_memfd_alloc: memfd_create with no sealing +qemu_memfd_alloc: memfd_create worked, truncating... +qemu_memfd_alloc: mmaping +qemu_memfd_free: enter +qemu_memfd_check: ok +vhost_dev_start: enter + +(scenario 2) + +Linux kvm01 3.13.0-99-generic #146-Ubuntu SMP Wed Oct 12 20:56:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux + +with: +-netdev tap,id=net0,vhost=on +-device virtio-net-pci,netdev=net0,id=net0,mac=52:54:00:20:c5:42,bus=pci.0,addr=0x3 + +## kvm01 + +$ ./instance.sh +qemu_memfd_check +qemu_memfd_alloc: enter +qemu_memfd_alloc: memfd_create with no sealing +qemu_memfd_alloc: memfd_create failed #2 +qemu_memfd_alloc: fallback +qemu_memfd_alloc: fname = /tmp/memfd-XXXXXX +qemu_memfd_alloc: fallback truncating +qemu_memfd_alloc: mmaping +qemu_memfd_free +qemu_memfd_check: ok +vhost_dev_start: enter +vhost_log_get: enter +vhost_log_alloc: enter +vhost_log_alloc: local +vhost_log_get: not shared +vhost_log_put: enter +vhost_log_put: enter +vhost_log_put: local free + +(qemu) migrate -d tcp:kvm02:4444 +(qemu) info migrate +capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compres +Migration status: completed +total time: 15400 milliseconds +downtime: 9 milliseconds +setup: 5 milliseconds +transferred ram: 375812 kbytes +throughput: 199.99 mbps +remaining ram: 0 kbytes +total ram: 4001544 kbytes +duplicate: 909186 pages +skipped: 0 pages +normal: 91776 pages +normal bytes: 367104 kbytes +dirty sync count: 3 + +## kvm02 + +$ ./instance.sh +qemu_memfd_check +qemu_memfd_alloc: enter +qemu_memfd_alloc: memfd_create with no sealing +qemu_memfd_alloc: memfd_create failed #2 +qemu_memfd_alloc: fallback +qemu_memfd_alloc: fname = /tmp/memfd-XXXXXX +qemu_memfd_alloc: fallback truncating +qemu_memfd_alloc: mmaping +qemu_memfd_free +qemu_memfd_check: ok +vhost_dev_start: enter + +For kvm01, we have 2 parts: + +(1) From "-netdev tap,id=net0,vhost=on": + - net_init_clients() + - net_init_client() + - net_client_init() + - net_client_init1() + - net_client_init_fun() .. net_init_tap() in my case + - net_init_tap_one() + - vhost_net_init() + - vhost_dev_init() + - migration checks (host feature, memfd functional test) + +(2) From "-device virtio-net-pci,netdev=net0...": + - virtio_pci_device_plugged() + - virtio_pci_modern_regions_init() + - virtio_pci_common_write() + - virtio_set_status() + - virtio_net_set_status() + - virtio_net_vhost_status() + - vhost_net_start() + - vhost_net_start_one() + - vhost_dev_start() + - does the log allocation logic + +It looks like "vhost_requires_shm_log" isn't defined by my underlaying VHOST driver (vhost-net in my case). It seems that vhost-user defines it (from VhostOps user_ops). + +Judging by the outputs above, looks like vhost_dev_log_is_shared is returning false, making (2) - vhost_dev_start - to use a different log allocation (malloc) than the one that was tested for allowing migrations at (1) - vhost_dev_init. + +Question: Why to check for "memfd" when its not sure - yet - if a shared descriptor and memory pointer is going to be needed for the migration to happen ? Do you want me to change that ? If memfd fails, but, the guest in question is using regular "malloc" for vhost log, we are marking it unable to live migrate by mistake. I could check for vhost_requires_shm_log pointer during vhost_dev_init (coming from tap). + +Also, if possible, I would like comments about a draft: + +https://pastebin.canonical.com/168579/ +(please disregard printfs and minor problems) + +OBS: I'm basically removing fallback mechanism from memfd, creating a generic qemu_mmap_XXX implementation, adding a vhostlog parameter in tap cmdline AND changing the decision on what to use: if vhostlog is present in cmdline, qemu_mmap_XXX on vhostlog is used. If it is a directory, a random file is created inside it. If it is a file, the file is used. If no vhostlog is given (default while libvirt isn't changed), it tries first to use memfd (all newer kernels), and, if not possible, it tries to fallback using the qemu_mmap mechanism on "tmp" directory creating random files. + +PS: Remember that this is because selinux/apparmor labelling on tmp files (and because file descriptors can be passed away, like we discussed before). + +If that is okay I'll provide a patch asap. Let me know if you prefer something else. + +Thank you, +Rafael + +> On Oct 04, 2016, at 12:29, Rafael David Tinoco <email address hidden> wrote: +> +> +>> On Oct 04, 2016, at 10:50, Marc-André Lureau <email address hidden> wrote: +>> +>> What about having a single config parameter as a place to put all vhost logs for all drives for a single instance ? Remove the memfd implementation with all the memfd shared_memory option ? Replace it with a open+unlink+ftruncate+mmap approach only. +>> +>> +>> I fail to see your point, memfd is superior to open+unlink and has other advantages with sealing etc. +> +> I was just summarising needs based on previous statement from Daniel: +> +>> This makes me wonder about the memfd_create() code path too - we'll +>> again not want that external process to be granted access to arbitrary +>> FDs of QEMU's and I'm not sure of a way to get the memfd FD to have +>> a specific label. So I think it is possible that when using libvirt +>> we'll want the ability to tell QEMU to *always* use an explicit file +>> in a path libvirt specifies, and never use memfd even if available. +>> +>> Regards, +>> Daniel + + + +The correct (and draft) one: +http://pastebin.ubuntu.com/23357210/ + +Im passing vhostlog parameter as "hdev->log_filename" so it can be accessed from net_init_tap()-> functions AND from vhost_dev_start()-> functions. This way I don't have to change function prototypes anymore. + +> On Oct 21, 2016, at 01:03, Rafael David Tinoco <email address hidden> wrote: +> +> Also, if possible, I would like comments about a draft: +> +> https://pastebin.canonical.com/168579/ +> (please disregard printfs and minor problems) + + + +Hi + +On Fri, Oct 21, 2016 at 6:03 AM Rafael David Tinoco < +<email address hidden>> wrote: + +> Judging by the outputs above, looks like vhost_dev_log_is_shared is +> returning false, making (2) - vhost_dev_start - to use a different log +> allocation (malloc) than the one that was tested for allowing migrations at +> (1) - vhost_dev_init. +> +> +correct + + +> Question: Why to check for "memfd" when its not sure - yet - if a shared +> descriptor and memory pointer is going to be needed for the migration to +> happen ? Do you want me to + + +It's done early enough to disable migration. + + +> change that ? If memfd fails, but, the guest in question is using regular +> "malloc" for vhost log, we are marking it unable to live migrate by +> mistake. I could check for vhost_requires_shm_log pointer during +> vhost_dev_init (coming from tap). +> +> +Right, it should be done only if vhost_dev_log_is_shared is true. Patch +welcome + + +> Also, if possible, I would like comments about a draft: +> +> https://pastebin.canonical.com/168579/ +> (please disregard printfs and minor problems) +> +> OBS: I'm basically removing fallback mechanism from memfd, creating a +> generic qemu_mmap_XXX implementation, adding a vhostlog parameter in tap +> cmdline AND changing the decision on what to use: if vhostlog is present in +> cmdline, qemu_mmap_XXX on vhostlog is used. If it is a directory, a random +> file is created inside it. If it is a file, the file is used. If no +> vhostlog is given (default while libvirt isn't changed), it tries first to +> use memfd (all newer kernels), and, if not possible, it tries to fallback +> using the qemu_mmap mechanism on "tmp" directory creating random files. +> + +Sounds reasonable, but I am not sure so many fallbacks are necessary. I +would just have an optional filename. + +> +> PS: Remember that this is because selinux/apparmor labelling on tmp files +> (and because file descriptors can be passed away, like we discussed before). +> +> If that is okay I'll provide a patch asap. Let me know if you prefer +> something else. +> + +Ok, I hope other comments on the idea, and I'll review your patch once on +the ML. + +Thanks +-- +Marc-André Lureau + + +Commit 31190ed7 added a migration blocker in vhost_dev_init() to +check if memfd would succeed. It is better if this blocker first +checks if vhost backend requires shared log. This will avoid a +situation where a blocker is added inappropriately (e.g. shared +log allocation fails when vhost backend doesn't support it). + +Commit: 35f9b6e added a fallback mechanism for systems not supporting +memfd_create syscall (started being supported since 3.17). + +Backporting memfd_create might not be accepted for distros relying +on older kernels. Nowadays there is no way for security driver +to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. + +Also, because vhost log file descriptors can be passed to other +processes, after discussion, we thought it is best to back mmap by +using files that can be placed into a specific directory: this commit +creates "vhostlog" argv parameter for such purpose. This will allow +security drivers to operate on those files appropriately. + +Argv examples: + + -netdev tap,id=net0,vhost=on + -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log + -netdev tap,id=net0,vhost=on,vhostlog=/tmp + +For vhost backends supporting shared logs, if vhostlog is non-existent, +or a directory, random files are going to be created in the specified +directory (or, for non-existent, in tmpdir). If vhostlog is specified, +the filepath is always used when allocating vhost log files. + +Signed-off-by: Rafael David Tinoco <email address hidden> +--- + hw/net/vhost_net.c | 4 +- + hw/scsi/vhost-scsi.c | 2 +- + hw/virtio/vhost-vsock.c | 2 +- + hw/virtio/vhost.c | 41 +++++++------ + include/hw/virtio/vhost.h | 4 +- + include/net/vhost_net.h | 1 + + include/qemu/mmap-file.h | 10 +++ + net/tap.c | 6 ++ + qapi-schema.json | 3 + + qemu-options.hx | 3 +- + util/Makefile.objs | 1 + + util/mmap-file.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++ + 12 files changed, 207 insertions(+), 23 deletions(-) + create mode 100644 include/qemu/mmap-file.h + create mode 100644 util/mmap-file.c + +diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c +index f2d49ad..d650c92 100644 +--- a/hw/net/vhost_net.c ++++ b/hw/net/vhost_net.c +@@ -171,8 +171,8 @@ struct vhost_net *vhost_net_init(VhostNetOptions *options) + net->dev.vq_index = net->nc->queue_index * net->dev.nvqs; + } + +- r = vhost_dev_init(&net->dev, options->opaque, +- options->backend_type, options->busyloop_timeout); ++ r = vhost_dev_init(&net->dev, options->opaque, options->backend_type, ++ options->busyloop_timeout, options->vhostlog); + if (r < 0) { + goto fail; + } +diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c +index 5b26946..5dc3d30 100644 +--- a/hw/scsi/vhost-scsi.c ++++ b/hw/scsi/vhost-scsi.c +@@ -248,7 +248,7 @@ static void vhost_scsi_realize(DeviceState *dev, Error **errp) + s->dev.backend_features = 0; + + ret = vhost_dev_init(&s->dev, (void *)(uintptr_t)vhostfd, +- VHOST_BACKEND_TYPE_KERNEL, 0); ++ VHOST_BACKEND_TYPE_KERNEL, 0, NULL); + if (ret < 0) { + error_setg(errp, "vhost-scsi: vhost initialization failed: %s", + strerror(-ret)); +diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c +index b481562..6cf6081 100644 +--- a/hw/virtio/vhost-vsock.c ++++ b/hw/virtio/vhost-vsock.c +@@ -342,7 +342,7 @@ static void vhost_vsock_device_realize(DeviceState *dev, Error **errp) + vsock->vhost_dev.nvqs = ARRAY_SIZE(vsock->vhost_vqs); + vsock->vhost_dev.vqs = vsock->vhost_vqs; + ret = vhost_dev_init(&vsock->vhost_dev, (void *)(uintptr_t)vhostfd, +- VHOST_BACKEND_TYPE_KERNEL, 0); ++ VHOST_BACKEND_TYPE_KERNEL, 0, NULL); + if (ret < 0) { + error_setg_errno(errp, -ret, "vhost-vsock: vhost_dev_init failed"); + goto err_virtio; +diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +index bd051ab..d874ebb 100644 +--- a/hw/virtio/vhost.c ++++ b/hw/virtio/vhost.c +@@ -20,7 +20,7 @@ + #include "qemu/atomic.h" + #include "qemu/range.h" + #include "qemu/error-report.h" +-#include "qemu/memfd.h" ++#include "qemu/mmap-file.h" + #include <linux/vhost.h> + #include "exec/address-spaces.h" + #include "hw/virtio/virtio-bus.h" +@@ -326,7 +326,7 @@ static uint64_t vhost_get_log_size(struct vhost_dev *dev) + return log_size; + } + +-static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) ++static struct vhost_log *vhost_log_alloc(char *path, uint64_t size, bool share) + { + struct vhost_log *log; + uint64_t logsize = size * sizeof(*(log->log)); +@@ -334,9 +334,7 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) + + log = g_new0(struct vhost_log, 1); + if (share) { +- log->log = qemu_memfd_alloc("vhost-log", logsize, +- F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL, +- &fd); ++ log->log = qemu_mmap_alloc(path, logsize, &fd); + memset(log->log, 0, logsize); + } else { + log->log = g_malloc0(logsize); +@@ -349,12 +347,12 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) + return log; + } + +-static struct vhost_log *vhost_log_get(uint64_t size, bool share) ++static struct vhost_log *vhost_log_get(char *path, uint64_t size, bool share) + { + struct vhost_log *log = share ? vhost_log_shm : vhost_log; + + if (!log || log->size != size) { +- log = vhost_log_alloc(size, share); ++ log = vhost_log_alloc(path, size, share); + if (share) { + vhost_log_shm = log; + } else { +@@ -388,8 +386,7 @@ static void vhost_log_put(struct vhost_dev *dev, bool sync) + g_free(log->log); + vhost_log = NULL; + } else if (vhost_log_shm == log) { +- qemu_memfd_free(log->log, log->size * sizeof(*(log->log)), +- log->fd); ++ qemu_mmap_free(log->log, log->size * sizeof(*(log->log)), log->fd); + vhost_log_shm = NULL; + } + +@@ -405,9 +402,12 @@ static bool vhost_dev_log_is_shared(struct vhost_dev *dev) + + static inline void vhost_dev_log_resize(struct vhost_dev *dev, uint64_t size) + { +- struct vhost_log *log = vhost_log_get(size, vhost_dev_log_is_shared(dev)); +- uint64_t log_base = (uintptr_t)log->log; + int r; ++ struct vhost_log *log; ++ uint64_t log_base; ++ ++ log = vhost_log_get(dev->log_filename, size, vhost_dev_log_is_shared(dev)); ++ log_base = (uintptr_t)log->log; + + /* inform backend of log switching, this must be done before + releasing the current log, to ensure no logging is lost */ +@@ -1049,7 +1049,8 @@ static void vhost_virtqueue_cleanup(struct vhost_virtqueue *vq) + } + + int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +- VhostBackendType backend_type, uint32_t busyloop_timeout) ++ VhostBackendType backend_type, ++ uint32_t busyloop_timeout, char *vhostlog) + { + uint64_t features; + int i, r, n_initialized_vqs = 0; +@@ -1118,11 +1119,18 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + .priority = 10 + }; + ++ hdev->log = NULL; ++ hdev->log_size = 0; ++ hdev->log_enabled = false; ++ hdev->log_filename = vhostlog ? g_strdup(vhostlog) : NULL; ++ g_free(vhostlog); ++ + if (hdev->migration_blocker == NULL) { + if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { + error_setg(&hdev->migration_blocker, + "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +- } else if (!qemu_memfd_check()) { ++ } else if (vhost_dev_log_is_shared(hdev) && ++ !qemu_mmap_check(hdev->log_filename)) { + error_setg(&hdev->migration_blocker, + "Migration disabled: failed to allocate shared memory"); + } +@@ -1135,9 +1143,6 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions)); + hdev->n_mem_sections = 0; + hdev->mem_sections = NULL; +- hdev->log = NULL; +- hdev->log_size = 0; +- hdev->log_enabled = false; + hdev->started = false; + hdev->memory_changed = false; + memory_listener_register(&hdev->memory_listener, &address_space_memory); +@@ -1175,6 +1180,7 @@ void vhost_dev_cleanup(struct vhost_dev *hdev) + if (hdev->vhost_ops) { + hdev->vhost_ops->vhost_backend_cleanup(hdev); + } ++ g_free(hdev->log_filename); + assert(!hdev->log); + + memset(hdev, 0, sizeof(struct vhost_dev)); +@@ -1335,7 +1341,8 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev) + uint64_t log_base; + + hdev->log_size = vhost_get_log_size(hdev); +- hdev->log = vhost_log_get(hdev->log_size, ++ hdev->log = vhost_log_get(hdev->log_filename, ++ hdev->log_size, + vhost_dev_log_is_shared(hdev)); + log_base = (uintptr_t)hdev->log->log; + r = hdev->vhost_ops->vhost_set_log_base(hdev, +diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h +index e433089..1ea4f3a 100644 +--- a/include/hw/virtio/vhost.h ++++ b/include/hw/virtio/vhost.h +@@ -52,6 +52,7 @@ struct vhost_dev { + uint64_t max_queues; + bool started; + bool log_enabled; ++ char *log_filename; + uint64_t log_size; + Error *migration_blocker; + bool memory_changed; +@@ -65,7 +66,8 @@ struct vhost_dev { + + int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + VhostBackendType backend_type, +- uint32_t busyloop_timeout); ++ uint32_t busyloop_timeout, ++ char *vhostlog); + void vhost_dev_cleanup(struct vhost_dev *hdev); + int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev); + void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev); +diff --git a/include/net/vhost_net.h b/include/net/vhost_net.h +index 5a08eff..94161b2 100644 +--- a/include/net/vhost_net.h ++++ b/include/net/vhost_net.h +@@ -12,6 +12,7 @@ typedef struct VhostNetOptions { + NetClientState *net_backend; + uint32_t busyloop_timeout; + void *opaque; ++ char *vhostlog; + } VhostNetOptions; + + uint64_t vhost_net_get_max_queues(VHostNetState *net); +diff --git a/include/qemu/mmap-file.h b/include/qemu/mmap-file.h +new file mode 100644 +index 0000000..427612a +--- /dev/null ++++ b/include/qemu/mmap-file.h +@@ -0,0 +1,10 @@ ++#ifndef QEMU_MMAP_FILE_H ++#define QEMU_MMAP_FILE_H ++ ++#include "qemu-common.h" ++ ++void *qemu_mmap_alloc(const char *path, size_t size, int *fd); ++void qemu_mmap_free(void *ptr, size_t size, int fd); ++bool qemu_mmap_check(const char *path); ++ ++#endif +diff --git a/net/tap.c b/net/tap.c +index b6896a7..7b242cd 100644 +--- a/net/tap.c ++++ b/net/tap.c +@@ -699,6 +699,12 @@ static void net_init_tap_one(const NetdevTapOptions *tap, NetClientState *peer, + } + options.opaque = (void *)(uintptr_t)vhostfd; + ++ if (tap->has_vhostlog) { ++ options.vhostlog = g_strdup(tap->vhostlog); ++ } else { ++ options.vhostlog = NULL; ++ } ++ + s->vhost_net = vhost_net_init(&options); + if (!s->vhost_net) { + error_setg(errp, +diff --git a/qapi-schema.json b/qapi-schema.json +index 5a8ec38..72608bd 100644 +--- a/qapi-schema.json ++++ b/qapi-schema.json +@@ -2640,6 +2640,8 @@ + # + # @vhostforce: #optional vhost on for non-MSIX virtio guests + # ++# @vhostlog: #optional file or directory for vhost backend log ++# + # @queues: #optional number of queues to be created for multiqueue capable tap + # + # @poll-us: #optional maximum number of microseconds that could +@@ -2662,6 +2664,7 @@ + '*vhostfd': 'str', + '*vhostfds': 'str', + '*vhostforce': 'bool', ++ '*vhostlog': 'str', + '*queues': 'uint32', + '*poll-us': 'uint32'} } + +diff --git a/qemu-options.hx b/qemu-options.hx +index b1fbdb0..5c09c09 100644 +--- a/qemu-options.hx ++++ b/qemu-options.hx +@@ -1599,7 +1599,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, + #else + "-netdev tap,id=str[,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile]\n" + " [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n" +- " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n]\n" ++ " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,vhostlog=file|dir][,queues=n]\n" + " [,poll-us=n]\n" + " configure a host TAP network backend with ID 'str'\n" + " connected to a bridge (default=" DEFAULT_BRIDGE_INTERFACE ")\n" +@@ -1618,6 +1618,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, + " use vhost=on to enable experimental in kernel accelerator\n" + " (only has effect for virtio guests which use MSIX)\n" + " use vhostforce=on to force vhost on for non-MSIX virtio guests\n" ++ " use 'vhostlog=file|dir' file or directory for vhost backend log\n" + " use 'vhostfd=h' to connect to an already opened vhost net device\n" + " use 'vhostfds=x:y:...:z to connect to multiple already opened vhost net devices\n" + " use 'queues=n' to specify the number of queues to be created for multiqueue TAP\n" +diff --git a/util/Makefile.objs b/util/Makefile.objs +index 36c7dcc..69bb27a 100644 +--- a/util/Makefile.objs ++++ b/util/Makefile.objs +@@ -3,6 +3,7 @@ util-obj-y += bufferiszero.o + util-obj-$(CONFIG_POSIX) += compatfd.o + util-obj-$(CONFIG_POSIX) += event_notifier-posix.o + util-obj-$(CONFIG_POSIX) += mmap-alloc.o ++util-obj-$(CONFIG_POSIX) += mmap-file.o + util-obj-$(CONFIG_POSIX) += oslib-posix.o + util-obj-$(CONFIG_POSIX) += qemu-openpty.o + util-obj-$(CONFIG_POSIX) += qemu-thread-posix.o +diff --git a/util/mmap-file.c b/util/mmap-file.c +new file mode 100644 +index 0000000..ce778cf +--- /dev/null ++++ b/util/mmap-file.c +@@ -0,0 +1,153 @@ ++/* ++ * Support for file backed by mmaped host memory. ++ * ++ * Authors: ++ * Rafael David Tinoco <email address hidden> ++ * ++ * This work is licensed under the terms of the GNU GPL, version 2 or ++ * later. See the COPYING file in the top-level directory. ++ */ ++ ++#include "qemu/osdep.h" ++#include "qemu/mmap-file.h" ++ ++static char *qemu_mmap_rand_name(void) ++{ ++ char *name; ++ GRand *rsufix; ++ guint32 sufix; ++ ++ rsufix = g_rand_new(); ++ sufix = g_rand_int(rsufix); ++ g_free(rsufix); ++ name = g_strdup_printf("mmap-%u", sufix); ++ ++ return name; ++} ++ ++static inline void qemu_mmap_rand_name_free(char *str) ++{ ++ g_free(str); ++} ++ ++static bool qemu_mmap_is(const char *path, mode_t what) ++{ ++ struct stat s; ++ ++ memset(&s, 0, sizeof(struct stat)); ++ if (stat(path, &s)) { ++ perror("stat"); ++ goto negative; ++ } ++ ++ if ((s.st_mode & S_IFMT) == what) { ++ return true; ++ } ++ ++negative: ++ return false; ++} ++ ++static inline bool qemu_mmap_is_file(const char *path) ++{ ++ return qemu_mmap_is(path, S_IFREG); ++} ++ ++static inline bool qemu_mmap_is_dir(const char *path) ++{ ++ return qemu_mmap_is(path, S_IFDIR); ++} ++ ++static void *qemu_mmap_alloc_file(const char *filepath, size_t size, int *fd) ++{ ++ void *ptr; ++ int mfd = -1; ++ ++ *fd = -1; ++ ++ mfd = open(filepath, O_CREAT | O_EXCL | O_RDWR, S_IRUSR | S_IWUSR); ++ if (mfd == -1) { ++ perror("open"); ++ return NULL; ++ } ++ ++ unlink(filepath); ++ ++ if (ftruncate(mfd, size) == -1) { ++ perror("ftruncate"); ++ close(mfd); ++ return NULL; ++ } ++ ++ ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); ++ if (ptr == MAP_FAILED) { ++ perror("mmap"); ++ close(mfd); ++ return NULL; ++ } ++ ++ *fd = mfd; ++ return ptr; ++} ++ ++static void *qemu_mmap_alloc_dir(const char *dirpath, size_t size, int *fd) ++{ ++ void *ptr; ++ char *file, *rand, *tmp, *dir2use = NULL; ++ ++ if (dirpath && !qemu_mmap_is_dir(dirpath)) { ++ return NULL; ++ } ++ ++ tmp = (char *) g_get_tmp_dir(); ++ dir2use = dirpath ? (char *) dirpath : tmp; ++ rand = qemu_mmap_rand_name(); ++ file = g_strdup_printf("%s/%s", dir2use, rand); ++ ptr = qemu_mmap_alloc_file(file, size, fd); ++ g_free(tmp); ++ qemu_mmap_rand_name_free(rand); ++ ++ return ptr; ++} ++ ++/* ++ * "path" can be: ++ * ++ * filename = full path for the file to back mmap ++ * dir path = full dir path where to create random file for mmap ++ * null = will use <tmpdir> to create random file for mmap ++ */ ++void *qemu_mmap_alloc(const char *path, size_t size, int *fd) ++{ ++ if (!path || qemu_mmap_is_dir(path)) { ++ return qemu_mmap_alloc_dir(path, size, fd); ++ } ++ ++ return qemu_mmap_alloc_file(path, size, fd); ++} ++ ++void qemu_mmap_free(void *ptr, size_t size, int fd) ++{ ++ if (ptr) { ++ munmap(ptr, size); ++ } ++ ++ if (fd != -1) { ++ close(fd); ++ } ++} ++ ++bool qemu_mmap_check(const char *path) ++{ ++ void *ptr; ++ int fd = -1; ++ bool r = true; ++ ++ ptr = qemu_mmap_alloc(path, 4096, &fd); ++ if (!ptr) { ++ r = false; ++ } ++ qemu_mmap_free(ptr, 4096, fd); ++ ++ return r == true ? true : false; ++} +-- +2.9.3 + + + +Commit 31190ed7 added a migration blocker in vhost_dev_init() to +check if memfd would succeed. It is better if this blocker first +checks if vhost backend requires shared log. This will avoid a +situation where a blocker is added inappropriately (e.g. shared +log allocation fails when vhost backend doesn't support it). +--- + hw/virtio/vhost.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +index bd051ab..742d0aa 100644 +--- a/hw/virtio/vhost.c ++++ b/hw/virtio/vhost.c +@@ -1122,7 +1122,7 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { + error_setg(&hdev->migration_blocker, + "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +- } else if (!qemu_memfd_check()) { ++ } else if (vhost_dev_log_is_shared(hdev) && !qemu_memfd_check()) { + error_setg(&hdev->migration_blocker, + "Migration disabled: failed to allocate shared memory"); + } +-- +2.9.3 + + + + +> Begin forwarded message: +> +> From: Marc-André Lureau <email address hidden> +> Subject: Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter +> Date: October 22, 2016 at 05:18:02 GMT-2 +> To: Rafael David Tinoco <email address hidden> +> Cc: QEMU <email address hidden> +> +> Hi +> +> On Sat, Oct 22, 2016 at 10:01 AM Rafael David Tinoco <<email address hidden> <mailto:<email address hidden>>> wrote: +> Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> check if memfd would succeed. It is better if this blocker first +> checks if vhost backend requires shared log. This will avoid a +> situation where a blocker is added inappropriately (e.g. shared +> log allocation fails when vhost backend doesn't support it). +> +> Could you make this a seperate patch? +> +> Commit: 35f9b6e added a fallback mechanism for systems not supporting +> memfd_create syscall (started being supported since 3.17). +> +> Backporting memfd_create might not be accepted for distros relying +> on older kernels. Nowadays there is no way for security driver +> to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> +> Also, because vhost log file descriptors can be passed to other +> processes, after discussion, we thought it is best to back mmap by +> using files that can be placed into a specific directory: this commit +> creates "vhostlog" argv parameter for such purpose. This will allow +> security drivers to operate on those files appropriately. +> +> Argv examples: +> +> -netdev tap,id=net0,vhost=on +> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> +> Could it be only a filename? This would simplify testing. +> +> +> For vhost backends supporting shared logs, if vhostlog is non-existent, +> or a directory, random files are going to be created in the specified +> directory (or, for non-existent, in tmpdir). If vhostlog is specified, +> the filepath is always used when allocating vhost log files. +> +> +> Regarding testing, you add utility code mmap-file, could you make this a seperate commit, with unit tests? +> +> thanks +> +> Signed-off-by: Rafael David Tinoco <<email address hidden> <mailto:<email address hidden>>> +> --- +> hw/net/vhost_net.c | 4 +- +> hw/scsi/vhost-scsi.c | 2 +- +> hw/virtio/vhost-vsock.c | 2 +- +> hw/virtio/vhost.c | 41 +++++++------ +> include/hw/virtio/vhost.h | 4 +- +> include/net/vhost_net.h | 1 + +> include/qemu/mmap-file.h | 10 +++ +> net/tap.c | 6 ++ +> qapi-schema.json | 3 + +> qemu-options.hx | 3 +- +> util/Makefile.objs | 1 + +> util/mmap-file.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++ +> 12 files changed, 207 insertions(+), 23 deletions(-) +> create mode 100644 include/qemu/mmap-file.h +> create mode 100644 util/mmap-file.c +> +> diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c +> index f2d49ad..d650c92 100644 +> --- a/hw/net/vhost_net.c +> +++ b/hw/net/vhost_net.c +> @@ -171,8 +171,8 @@ struct vhost_net *vhost_net_init(VhostNetOptions *options) +> net->dev.vq_index = net->nc->queue_index * net->dev.nvqs; +> } +> +> - r = vhost_dev_init(&net->dev, options->opaque, +> - options->backend_type, options->busyloop_timeout); +> + r = vhost_dev_init(&net->dev, options->opaque, options->backend_type, +> + options->busyloop_timeout, options->vhostlog); +> if (r < 0) { +> goto fail; +> } +> diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c +> index 5b26946..5dc3d30 100644 +> --- a/hw/scsi/vhost-scsi.c +> +++ b/hw/scsi/vhost-scsi.c +> @@ -248,7 +248,7 @@ static void vhost_scsi_realize(DeviceState *dev, Error **errp) +> s->dev.backend_features = 0; +> +> ret = vhost_dev_init(&s->dev, (void *)(uintptr_t)vhostfd, +> - VHOST_BACKEND_TYPE_KERNEL, 0); +> + VHOST_BACKEND_TYPE_KERNEL, 0, NULL); +> if (ret < 0) { +> error_setg(errp, "vhost-scsi: vhost initialization failed: %s", +> strerror(-ret)); +> diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c +> index b481562..6cf6081 100644 +> --- a/hw/virtio/vhost-vsock.c +> +++ b/hw/virtio/vhost-vsock.c +> @@ -342,7 +342,7 @@ static void vhost_vsock_device_realize(DeviceState *dev, Error **errp) +> vsock->vhost_dev.nvqs = ARRAY_SIZE(vsock->vhost_vqs); +> vsock->vhost_dev.vqs = vsock->vhost_vqs; +> ret = vhost_dev_init(&vsock->vhost_dev, (void *)(uintptr_t)vhostfd, +> - VHOST_BACKEND_TYPE_KERNEL, 0); +> + VHOST_BACKEND_TYPE_KERNEL, 0, NULL); +> if (ret < 0) { +> error_setg_errno(errp, -ret, "vhost-vsock: vhost_dev_init failed"); +> goto err_virtio; +> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +> index bd051ab..d874ebb 100644 +> --- a/hw/virtio/vhost.c +> +++ b/hw/virtio/vhost.c +> @@ -20,7 +20,7 @@ +> #include "qemu/atomic.h" +> #include "qemu/range.h" +> #include "qemu/error-report.h" +> -#include "qemu/memfd.h" +> +#include "qemu/mmap-file.h" +> #include <linux/vhost.h> +> #include "exec/address-spaces.h" +> #include "hw/virtio/virtio-bus.h" +> @@ -326,7 +326,7 @@ static uint64_t vhost_get_log_size(struct vhost_dev *dev) +> return log_size; +> } +> +> -static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> +static struct vhost_log *vhost_log_alloc(char *path, uint64_t size, bool share) +> { +> struct vhost_log *log; +> uint64_t logsize = size * sizeof(*(log->log)); +> @@ -334,9 +334,7 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> +> log = g_new0(struct vhost_log, 1); +> if (share) { +> - log->log = qemu_memfd_alloc("vhost-log", logsize, +> - F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL, +> - &fd); +> + log->log = qemu_mmap_alloc(path, logsize, &fd); +> memset(log->log, 0, logsize); +> } else { +> log->log = g_malloc0(logsize); +> @@ -349,12 +347,12 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> return log; +> } +> +> -static struct vhost_log *vhost_log_get(uint64_t size, bool share) +> +static struct vhost_log *vhost_log_get(char *path, uint64_t size, bool share) +> { +> struct vhost_log *log = share ? vhost_log_shm : vhost_log; +> +> if (!log || log->size != size) { +> - log = vhost_log_alloc(size, share); +> + log = vhost_log_alloc(path, size, share); +> if (share) { +> vhost_log_shm = log; +> } else { +> @@ -388,8 +386,7 @@ static void vhost_log_put(struct vhost_dev *dev, bool sync) +> g_free(log->log); +> vhost_log = NULL; +> } else if (vhost_log_shm == log) { +> - qemu_memfd_free(log->log, log->size * sizeof(*(log->log)), +> - log->fd); +> + qemu_mmap_free(log->log, log->size * sizeof(*(log->log)), log->fd); +> vhost_log_shm = NULL; +> } +> +> @@ -405,9 +402,12 @@ static bool vhost_dev_log_is_shared(struct vhost_dev *dev) +> +> static inline void vhost_dev_log_resize(struct vhost_dev *dev, uint64_t size) +> { +> - struct vhost_log *log = vhost_log_get(size, vhost_dev_log_is_shared(dev)); +> - uint64_t log_base = (uintptr_t)log->log; +> int r; +> + struct vhost_log *log; +> + uint64_t log_base; +> + +> + log = vhost_log_get(dev->log_filename, size, vhost_dev_log_is_shared(dev)); +> + log_base = (uintptr_t)log->log; +> +> /* inform backend of log switching, this must be done before +> releasing the current log, to ensure no logging is lost */ +> @@ -1049,7 +1049,8 @@ static void vhost_virtqueue_cleanup(struct vhost_virtqueue *vq) +> } +> +> int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> - VhostBackendType backend_type, uint32_t busyloop_timeout) +> + VhostBackendType backend_type, +> + uint32_t busyloop_timeout, char *vhostlog) +> { +> uint64_t features; +> int i, r, n_initialized_vqs = 0; +> @@ -1118,11 +1119,18 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> .priority = 10 +> }; +> +> + hdev->log = NULL; +> + hdev->log_size = 0; +> + hdev->log_enabled = false; +> + hdev->log_filename = vhostlog ? g_strdup(vhostlog) : NULL; +> + g_free(vhostlog); +> + +> if (hdev->migration_blocker == NULL) { +> if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { +> error_setg(&hdev->migration_blocker, +> "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +> - } else if (!qemu_memfd_check()) { +> + } else if (vhost_dev_log_is_shared(hdev) && +> + !qemu_mmap_check(hdev->log_filename)) { +> error_setg(&hdev->migration_blocker, +> "Migration disabled: failed to allocate shared memory"); +> } +> @@ -1135,9 +1143,6 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions)); +> hdev->n_mem_sections = 0; +> hdev->mem_sections = NULL; +> - hdev->log = NULL; +> - hdev->log_size = 0; +> - hdev->log_enabled = false; +> hdev->started = false; +> hdev->memory_changed = false; +> memory_listener_register(&hdev->memory_listener, &address_space_memory); +> @@ -1175,6 +1180,7 @@ void vhost_dev_cleanup(struct vhost_dev *hdev) +> if (hdev->vhost_ops) { +> hdev->vhost_ops->vhost_backend_cleanup(hdev); +> } +> + g_free(hdev->log_filename); +> assert(!hdev->log); +> +> memset(hdev, 0, sizeof(struct vhost_dev)); +> @@ -1335,7 +1341,8 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev) +> uint64_t log_base; +> +> hdev->log_size = vhost_get_log_size(hdev); +> - hdev->log = vhost_log_get(hdev->log_size, +> + hdev->log = vhost_log_get(hdev->log_filename, +> + hdev->log_size, +> vhost_dev_log_is_shared(hdev)); +> log_base = (uintptr_t)hdev->log->log; +> r = hdev->vhost_ops->vhost_set_log_base(hdev, +> diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h +> index e433089..1ea4f3a 100644 +> --- a/include/hw/virtio/vhost.h +> +++ b/include/hw/virtio/vhost.h +> @@ -52,6 +52,7 @@ struct vhost_dev { +> uint64_t max_queues; +> bool started; +> bool log_enabled; +> + char *log_filename; +> uint64_t log_size; +> Error *migration_blocker; +> bool memory_changed; +> @@ -65,7 +66,8 @@ struct vhost_dev { +> +> int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> VhostBackendType backend_type, +> - uint32_t busyloop_timeout); +> + uint32_t busyloop_timeout, +> + char *vhostlog); +> void vhost_dev_cleanup(struct vhost_dev *hdev); +> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev); +> void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev); +> diff --git a/include/net/vhost_net.h b/include/net/vhost_net.h +> index 5a08eff..94161b2 100644 +> --- a/include/net/vhost_net.h +> +++ b/include/net/vhost_net.h +> @@ -12,6 +12,7 @@ typedef struct VhostNetOptions { +> NetClientState *net_backend; +> uint32_t busyloop_timeout; +> void *opaque; +> + char *vhostlog; +> } VhostNetOptions; +> +> uint64_t vhost_net_get_max_queues(VHostNetState *net); +> diff --git a/include/qemu/mmap-file.h b/include/qemu/mmap-file.h +> new file mode 100644 +> index 0000000..427612a +> --- /dev/null +> +++ b/include/qemu/mmap-file.h +> @@ -0,0 +1,10 @@ +> +#ifndef QEMU_MMAP_FILE_H +> +#define QEMU_MMAP_FILE_H +> + +> +#include "qemu-common.h" +> + +> +void *qemu_mmap_alloc(const char *path, size_t size, int *fd); +> +void qemu_mmap_free(void *ptr, size_t size, int fd); +> +bool qemu_mmap_check(const char *path); +> + +> +#endif +> diff --git a/net/tap.c b/net/tap.c +> index b6896a7..7b242cd 100644 +> --- a/net/tap.c +> +++ b/net/tap.c +> @@ -699,6 +699,12 @@ static void net_init_tap_one(const NetdevTapOptions *tap, NetClientState *peer, +> } +> options.opaque = (void *)(uintptr_t)vhostfd; +> +> + if (tap->has_vhostlog) { +> + options.vhostlog = g_strdup(tap->vhostlog); +> + } else { +> + options.vhostlog = NULL; +> + } +> + +> s->vhost_net = vhost_net_init(&options); +> if (!s->vhost_net) { +> error_setg(errp, +> diff --git a/qapi-schema.json b/qapi-schema.json +> index 5a8ec38..72608bd 100644 +> --- a/qapi-schema.json +> +++ b/qapi-schema.json +> @@ -2640,6 +2640,8 @@ +> # +> # @vhostforce: #optional vhost on for non-MSIX virtio guests +> # +> +# @vhostlog: #optional file or directory for vhost backend log +> +# +> # @queues: #optional number of queues to be created for multiqueue capable tap +> # +> # @poll-us: #optional maximum number of microseconds that could +> @@ -2662,6 +2664,7 @@ +> '*vhostfd': 'str', +> '*vhostfds': 'str', +> '*vhostforce': 'bool', +> + '*vhostlog': 'str', +> '*queues': 'uint32', +> '*poll-us': 'uint32'} } +> +> diff --git a/qemu-options.hx b/qemu-options.hx +> index b1fbdb0..5c09c09 100644 +> --- a/qemu-options.hx +> +++ b/qemu-options.hx +> @@ -1599,7 +1599,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, +> #else +> "-netdev tap,id=str[,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile]\n" +> " [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n" +> - " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n]\n" +> + " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,vhostlog=file|dir][,queues=n]\n" +> " [,poll-us=n]\n" +> " configure a host TAP network backend with ID 'str'\n" +> " connected to a bridge (default=" DEFAULT_BRIDGE_INTERFACE ")\n" +> @@ -1618,6 +1618,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, +> " use vhost=on to enable experimental in kernel accelerator\n" +> " (only has effect for virtio guests which use MSIX)\n" +> " use vhostforce=on to force vhost on for non-MSIX virtio guests\n" +> + " use 'vhostlog=file|dir' file or directory for vhost backend log\n" +> " use 'vhostfd=h' to connect to an already opened vhost net device\n" +> " use 'vhostfds=x:y:...:z to connect to multiple already opened vhost net devices\n" +> " use 'queues=n' to specify the number of queues to be created for multiqueue TAP\n" +> diff --git a/util/Makefile.objs b/util/Makefile.objs +> index 36c7dcc..69bb27a 100644 +> --- a/util/Makefile.objs +> +++ b/util/Makefile.objs +> @@ -3,6 +3,7 @@ util-obj-y += bufferiszero.o +> util-obj-$(CONFIG_POSIX) += compatfd.o +> util-obj-$(CONFIG_POSIX) += event_notifier-posix.o +> util-obj-$(CONFIG_POSIX) += mmap-alloc.o +> +util-obj-$(CONFIG_POSIX) += mmap-file.o +> util-obj-$(CONFIG_POSIX) += oslib-posix.o +> util-obj-$(CONFIG_POSIX) += qemu-openpty.o +> util-obj-$(CONFIG_POSIX) += qemu-thread-posix.o +> diff --git a/util/mmap-file.c b/util/mmap-file.c +> new file mode 100644 +> index 0000000..ce778cf +> --- /dev/null +> +++ b/util/mmap-file.c +> @@ -0,0 +1,153 @@ +> +/* +> + * Support for file backed by mmaped host memory. +> + * +> + * Authors: +> + * Rafael David Tinoco <<email address hidden> <mailto:<email address hidden>>> +> + * +> + * This work is licensed under the terms of the GNU GPL, version 2 or +> + * later. See the COPYING file in the top-level directory. +> + */ +> + +> +#include "qemu/osdep.h" +> +#include "qemu/mmap-file.h" +> + +> +static char *qemu_mmap_rand_name(void) +> +{ +> + char *name; +> + GRand *rsufix; +> + guint32 sufix; +> + +> + rsufix = g_rand_new(); +> + sufix = g_rand_int(rsufix); +> + g_free(rsufix); +> + name = g_strdup_printf("mmap-%u", sufix); +> + +> + return name; +> +} +> + +> +static inline void qemu_mmap_rand_name_free(char *str) +> +{ +> + g_free(str); +> +} +> + +> +static bool qemu_mmap_is(const char *path, mode_t what) +> +{ +> + struct stat s; +> + +> + memset(&s, 0, sizeof(struct stat)); +> + if (stat(path, &s)) { +> + perror("stat"); +> + goto negative; +> + } +> + +> + if ((s.st_mode & S_IFMT) == what) { +> + return true; +> + } +> + +> +negative: +> + return false; +> +} +> + +> +static inline bool qemu_mmap_is_file(const char *path) +> +{ +> + return qemu_mmap_is(path, S_IFREG); +> +} +> + +> +static inline bool qemu_mmap_is_dir(const char *path) +> +{ +> + return qemu_mmap_is(path, S_IFDIR); +> +} +> + +> +static void *qemu_mmap_alloc_file(const char *filepath, size_t size, int *fd) +> +{ +> + void *ptr; +> + int mfd = -1; +> + +> + *fd = -1; +> + +> + mfd = open(filepath, O_CREAT | O_EXCL | O_RDWR, S_IRUSR | S_IWUSR); +> + if (mfd == -1) { +> + perror("open"); +> + return NULL; +> + } +> + +> + unlink(filepath); +> + +> + if (ftruncate(mfd, size) == -1) { +> + perror("ftruncate"); +> + close(mfd); +> + return NULL; +> + } +> + +> + ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); +> + if (ptr == MAP_FAILED) { +> + perror("mmap"); +> + close(mfd); +> + return NULL; +> + } +> + +> + *fd = mfd; +> + return ptr; +> +} +> + +> +static void *qemu_mmap_alloc_dir(const char *dirpath, size_t size, int *fd) +> +{ +> + void *ptr; +> + char *file, *rand, *tmp, *dir2use = NULL; +> + +> + if (dirpath && !qemu_mmap_is_dir(dirpath)) { +> + return NULL; +> + } +> + +> + tmp = (char *) g_get_tmp_dir(); +> + dir2use = dirpath ? (char *) dirpath : tmp; +> + rand = qemu_mmap_rand_name(); +> + file = g_strdup_printf("%s/%s", dir2use, rand); +> + ptr = qemu_mmap_alloc_file(file, size, fd); +> + g_free(tmp); +> + qemu_mmap_rand_name_free(rand); +> + +> + return ptr; +> +} +> + +> +/* +> + * "path" can be: +> + * +> + * filename = full path for the file to back mmap +> + * dir path = full dir path where to create random file for mmap +> + * null = will use <tmpdir> to create random file for mmap +> + */ +> +void *qemu_mmap_alloc(const char *path, size_t size, int *fd) +> +{ +> + if (!path || qemu_mmap_is_dir(path)) { +> + return qemu_mmap_alloc_dir(path, size, fd); +> + } +> + +> + return qemu_mmap_alloc_file(path, size, fd); +> +} +> + +> +void qemu_mmap_free(void *ptr, size_t size, int fd) +> +{ +> + if (ptr) { +> + munmap(ptr, size); +> + } +> + +> + if (fd != -1) { +> + close(fd); +> + } +> +} +> + +> +bool qemu_mmap_check(const char *path) +> +{ +> + void *ptr; +> + int fd = -1; +> + bool r = true; +> + +> + ptr = qemu_mmap_alloc(path, 4096, &fd); +> + if (!ptr) { +> + r = false; +> + } +> + qemu_mmap_free(ptr, 4096, fd); +> + +> + return r == true ? true : false; +> +} +> -- +> 2.9.3 +> +> +> -- +> Marc-André Lureau + + + + + +> Begin forwarded message: +> +> From: Rafael David Tinoco <email address hidden> +> Subject: Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter +> Date: October 22, 2016 at 19:52:31 GMT-2 +> To: Marc-André Lureau <email address hidden> +> Cc: Rafael David Tinoco <email address hidden>, qemu-devel <email address hidden> +> +> Hello, +> +>> On Oct 22, 2016, at 05:18, Marc-André Lureau <email address hidden> wrote: +>> +>> Hi +>> +>> On Sat, Oct 22, 2016 at 10:01 AM Rafael David Tinoco <email address hidden> wrote: +>> Commit 31190ed7 added a migration blocker in vhost_dev_init() to +>> check if memfd would succeed. It is better if this blocker first +>> checks if vhost backend requires shared log. This will avoid a +>> situation where a blocker is added inappropriately (e.g. shared +>> log allocation fails when vhost backend doesn't support it). +>> +>> Could you make this a seperate patch? +> +> Just did, in another e-mail, cc'ing you. +> +>> Argv examples: +>> +>> -netdev tap,id=net0,vhost=on +>> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +>> -netdev tap,id=net0,vhost=on,vhostlog=/tmp +>> +>> Could it be only a filename? This would simplify testing. +> +> It could. Should I keep the /tmp/<random> logic if no vhostlog arg is present ? Or you think it should fail if no arg is given ? I'm afraid of backward compatibility when back-porting this to older qemu versions on stable releases (like my case: I'll backport this to ~3 different versions). +> +>> For vhost backends supporting shared logs, if vhostlog is non-existent, +>> or a directory, random files are going to be created in the specified +>> directory (or, for non-existent, in tmpdir). If vhostlog is specified, +>> the filepath is always used when allocating vhost log files. +>> +>> +>> Regarding testing, you add utility code mmap-file, could you make this a seperate commit, with unit tests? +>> +> +> Sure, I'll work on it. +> +>> thanks +> +> Thank u! +> +> -Rafael Tinoco + + + +Commit 31190ed7 added a migration blocker in vhost_dev_init() to +check if memfd would succeed. It is better if this blocker first +checks if vhost backend requires shared log. This will avoid a +situation where a blocker is added inappropriately (e.g. shared +log allocation fails when vhost backend doesn't support it). + +Signed-off-by: Rafael David Tinoco <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +--- + hw/virtio/vhost.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +index bd051ab..742d0aa 100644 +--- a/hw/virtio/vhost.c ++++ b/hw/virtio/vhost.c +@@ -1122,7 +1122,7 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { + error_setg(&hdev->migration_blocker, + "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +- } else if (!qemu_memfd_check()) { ++ } else if (vhost_dev_log_is_shared(hdev) && !qemu_memfd_check()) { + error_setg(&hdev->migration_blocker, + "Migration disabled: failed to allocate shared memory"); + } +-- +2.9.3 + + + +On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +> Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> check if memfd would succeed. It is better if this blocker first +> checks if vhost backend requires shared log. This will avoid a +> situation where a blocker is added inappropriately (e.g. shared +> log allocation fails when vhost backend doesn't support it). + +Sounds like a bugfix but I'm not sure. Can this part be split +out in a patch by itself? + +> Commit: 35f9b6e added a fallback mechanism for systems not supporting +> memfd_create syscall (started being supported since 3.17). +> +> Backporting memfd_create might not be accepted for distros relying +> on older kernels. Nowadays there is no way for security driver +> to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> +> Also, because vhost log file descriptors can be passed to other +> processes, after discussion, we thought it is best to back mmap by +> using files that can be placed into a specific directory: this commit +> creates "vhostlog" argv parameter for such purpose. This will allow +> security drivers to operate on those files appropriately. +> +> Argv examples: +> +> -netdev tap,id=net0,vhost=on +> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> +> For vhost backends supporting shared logs, if vhostlog is non-existent, +> or a directory, random files are going to be created in the specified +> directory (or, for non-existent, in tmpdir). If vhostlog is specified, +> the filepath is always used when allocating vhost log files. + +When vhostlog is not specified, can we just use memfd as we did? + +> Signed-off-by: Rafael David Tinoco <email address hidden> +> --- +> hw/net/vhost_net.c | 4 +- +> hw/scsi/vhost-scsi.c | 2 +- +> hw/virtio/vhost-vsock.c | 2 +- +> hw/virtio/vhost.c | 41 +++++++------ +> include/hw/virtio/vhost.h | 4 +- +> include/net/vhost_net.h | 1 + +> include/qemu/mmap-file.h | 10 +++ +> net/tap.c | 6 ++ +> qapi-schema.json | 3 + +> qemu-options.hx | 3 +- +> util/Makefile.objs | 1 + +> util/mmap-file.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++ +> 12 files changed, 207 insertions(+), 23 deletions(-) +> create mode 100644 include/qemu/mmap-file.h +> create mode 100644 util/mmap-file.c +> +> diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c +> index f2d49ad..d650c92 100644 +> --- a/hw/net/vhost_net.c +> +++ b/hw/net/vhost_net.c +> @@ -171,8 +171,8 @@ struct vhost_net *vhost_net_init(VhostNetOptions *options) +> net->dev.vq_index = net->nc->queue_index * net->dev.nvqs; +> } +> +> - r = vhost_dev_init(&net->dev, options->opaque, +> - options->backend_type, options->busyloop_timeout); +> + r = vhost_dev_init(&net->dev, options->opaque, options->backend_type, +> + options->busyloop_timeout, options->vhostlog); +> if (r < 0) { +> goto fail; +> } +> diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c +> index 5b26946..5dc3d30 100644 +> --- a/hw/scsi/vhost-scsi.c +> +++ b/hw/scsi/vhost-scsi.c +> @@ -248,7 +248,7 @@ static void vhost_scsi_realize(DeviceState *dev, Error **errp) +> s->dev.backend_features = 0; +> +> ret = vhost_dev_init(&s->dev, (void *)(uintptr_t)vhostfd, +> - VHOST_BACKEND_TYPE_KERNEL, 0); +> + VHOST_BACKEND_TYPE_KERNEL, 0, NULL); +> if (ret < 0) { +> error_setg(errp, "vhost-scsi: vhost initialization failed: %s", +> strerror(-ret)); +> diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c +> index b481562..6cf6081 100644 +> --- a/hw/virtio/vhost-vsock.c +> +++ b/hw/virtio/vhost-vsock.c +> @@ -342,7 +342,7 @@ static void vhost_vsock_device_realize(DeviceState *dev, Error **errp) +> vsock->vhost_dev.nvqs = ARRAY_SIZE(vsock->vhost_vqs); +> vsock->vhost_dev.vqs = vsock->vhost_vqs; +> ret = vhost_dev_init(&vsock->vhost_dev, (void *)(uintptr_t)vhostfd, +> - VHOST_BACKEND_TYPE_KERNEL, 0); +> + VHOST_BACKEND_TYPE_KERNEL, 0, NULL); +> if (ret < 0) { +> error_setg_errno(errp, -ret, "vhost-vsock: vhost_dev_init failed"); +> goto err_virtio; +> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +> index bd051ab..d874ebb 100644 +> --- a/hw/virtio/vhost.c +> +++ b/hw/virtio/vhost.c +> @@ -20,7 +20,7 @@ +> #include "qemu/atomic.h" +> #include "qemu/range.h" +> #include "qemu/error-report.h" +> -#include "qemu/memfd.h" +> +#include "qemu/mmap-file.h" +> #include <linux/vhost.h> +> #include "exec/address-spaces.h" +> #include "hw/virtio/virtio-bus.h" +> @@ -326,7 +326,7 @@ static uint64_t vhost_get_log_size(struct vhost_dev *dev) +> return log_size; +> } +> +> -static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> +static struct vhost_log *vhost_log_alloc(char *path, uint64_t size, bool share) +> { +> struct vhost_log *log; +> uint64_t logsize = size * sizeof(*(log->log)); +> @@ -334,9 +334,7 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> +> log = g_new0(struct vhost_log, 1); +> if (share) { +> - log->log = qemu_memfd_alloc("vhost-log", logsize, +> - F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL, +> - &fd); +> + log->log = qemu_mmap_alloc(path, logsize, &fd); +> memset(log->log, 0, logsize); +> } else { +> log->log = g_malloc0(logsize); +> @@ -349,12 +347,12 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> return log; +> } +> +> -static struct vhost_log *vhost_log_get(uint64_t size, bool share) +> +static struct vhost_log *vhost_log_get(char *path, uint64_t size, bool share) +> { +> struct vhost_log *log = share ? vhost_log_shm : vhost_log; +> +> if (!log || log->size != size) { +> - log = vhost_log_alloc(size, share); +> + log = vhost_log_alloc(path, size, share); +> if (share) { +> vhost_log_shm = log; +> } else { +> @@ -388,8 +386,7 @@ static void vhost_log_put(struct vhost_dev *dev, bool sync) +> g_free(log->log); +> vhost_log = NULL; +> } else if (vhost_log_shm == log) { +> - qemu_memfd_free(log->log, log->size * sizeof(*(log->log)), +> - log->fd); +> + qemu_mmap_free(log->log, log->size * sizeof(*(log->log)), log->fd); +> vhost_log_shm = NULL; +> } +> +> @@ -405,9 +402,12 @@ static bool vhost_dev_log_is_shared(struct vhost_dev *dev) +> +> static inline void vhost_dev_log_resize(struct vhost_dev *dev, uint64_t size) +> { +> - struct vhost_log *log = vhost_log_get(size, vhost_dev_log_is_shared(dev)); +> - uint64_t log_base = (uintptr_t)log->log; +> int r; +> + struct vhost_log *log; +> + uint64_t log_base; +> + +> + log = vhost_log_get(dev->log_filename, size, vhost_dev_log_is_shared(dev)); +> + log_base = (uintptr_t)log->log; +> +> /* inform backend of log switching, this must be done before +> releasing the current log, to ensure no logging is lost */ +> @@ -1049,7 +1049,8 @@ static void vhost_virtqueue_cleanup(struct vhost_virtqueue *vq) +> } +> +> int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> - VhostBackendType backend_type, uint32_t busyloop_timeout) +> + VhostBackendType backend_type, +> + uint32_t busyloop_timeout, char *vhostlog) +> { +> uint64_t features; +> int i, r, n_initialized_vqs = 0; +> @@ -1118,11 +1119,18 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> .priority = 10 +> }; +> +> + hdev->log = NULL; +> + hdev->log_size = 0; +> + hdev->log_enabled = false; +> + hdev->log_filename = vhostlog ? g_strdup(vhostlog) : NULL; +> + g_free(vhostlog); +> + +> if (hdev->migration_blocker == NULL) { +> if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { +> error_setg(&hdev->migration_blocker, +> "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +> - } else if (!qemu_memfd_check()) { +> + } else if (vhost_dev_log_is_shared(hdev) && +> + !qemu_mmap_check(hdev->log_filename)) { +> error_setg(&hdev->migration_blocker, +> "Migration disabled: failed to allocate shared memory"); +> } +> @@ -1135,9 +1143,6 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions)); +> hdev->n_mem_sections = 0; +> hdev->mem_sections = NULL; +> - hdev->log = NULL; +> - hdev->log_size = 0; +> - hdev->log_enabled = false; +> hdev->started = false; +> hdev->memory_changed = false; +> memory_listener_register(&hdev->memory_listener, &address_space_memory); +> @@ -1175,6 +1180,7 @@ void vhost_dev_cleanup(struct vhost_dev *hdev) +> if (hdev->vhost_ops) { +> hdev->vhost_ops->vhost_backend_cleanup(hdev); +> } +> + g_free(hdev->log_filename); +> assert(!hdev->log); +> +> memset(hdev, 0, sizeof(struct vhost_dev)); +> @@ -1335,7 +1341,8 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev) +> uint64_t log_base; +> +> hdev->log_size = vhost_get_log_size(hdev); +> - hdev->log = vhost_log_get(hdev->log_size, +> + hdev->log = vhost_log_get(hdev->log_filename, +> + hdev->log_size, +> vhost_dev_log_is_shared(hdev)); +> log_base = (uintptr_t)hdev->log->log; +> r = hdev->vhost_ops->vhost_set_log_base(hdev, +> diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h +> index e433089..1ea4f3a 100644 +> --- a/include/hw/virtio/vhost.h +> +++ b/include/hw/virtio/vhost.h +> @@ -52,6 +52,7 @@ struct vhost_dev { +> uint64_t max_queues; +> bool started; +> bool log_enabled; +> + char *log_filename; +> uint64_t log_size; +> Error *migration_blocker; +> bool memory_changed; +> @@ -65,7 +66,8 @@ struct vhost_dev { +> +> int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> VhostBackendType backend_type, +> - uint32_t busyloop_timeout); +> + uint32_t busyloop_timeout, +> + char *vhostlog); +> void vhost_dev_cleanup(struct vhost_dev *hdev); +> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev); +> void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev); +> diff --git a/include/net/vhost_net.h b/include/net/vhost_net.h +> index 5a08eff..94161b2 100644 +> --- a/include/net/vhost_net.h +> +++ b/include/net/vhost_net.h +> @@ -12,6 +12,7 @@ typedef struct VhostNetOptions { +> NetClientState *net_backend; +> uint32_t busyloop_timeout; +> void *opaque; +> + char *vhostlog; +> } VhostNetOptions; +> +> uint64_t vhost_net_get_max_queues(VHostNetState *net); +> diff --git a/include/qemu/mmap-file.h b/include/qemu/mmap-file.h +> new file mode 100644 +> index 0000000..427612a +> --- /dev/null +> +++ b/include/qemu/mmap-file.h +> @@ -0,0 +1,10 @@ +> +#ifndef QEMU_MMAP_FILE_H +> +#define QEMU_MMAP_FILE_H +> + +> +#include "qemu-common.h" +> + +> +void *qemu_mmap_alloc(const char *path, size_t size, int *fd); +> +void qemu_mmap_free(void *ptr, size_t size, int fd); +> +bool qemu_mmap_check(const char *path); +> + +> +#endif +> diff --git a/net/tap.c b/net/tap.c +> index b6896a7..7b242cd 100644 +> --- a/net/tap.c +> +++ b/net/tap.c +> @@ -699,6 +699,12 @@ static void net_init_tap_one(const NetdevTapOptions *tap, NetClientState *peer, +> } +> options.opaque = (void *)(uintptr_t)vhostfd; +> +> + if (tap->has_vhostlog) { +> + options.vhostlog = g_strdup(tap->vhostlog); +> + } else { +> + options.vhostlog = NULL; +> + } +> + +> s->vhost_net = vhost_net_init(&options); +> if (!s->vhost_net) { +> error_setg(errp, +> diff --git a/qapi-schema.json b/qapi-schema.json +> index 5a8ec38..72608bd 100644 +> --- a/qapi-schema.json +> +++ b/qapi-schema.json +> @@ -2640,6 +2640,8 @@ +> # +> # @vhostforce: #optional vhost on for non-MSIX virtio guests +> # +> +# @vhostlog: #optional file or directory for vhost backend log +> +# +> # @queues: #optional number of queues to be created for multiqueue capable tap +> # +> # @poll-us: #optional maximum number of microseconds that could +> @@ -2662,6 +2664,7 @@ +> '*vhostfd': 'str', +> '*vhostfds': 'str', +> '*vhostforce': 'bool', +> + '*vhostlog': 'str', +> '*queues': 'uint32', +> '*poll-us': 'uint32'} } +> +> diff --git a/qemu-options.hx b/qemu-options.hx +> index b1fbdb0..5c09c09 100644 +> --- a/qemu-options.hx +> +++ b/qemu-options.hx +> @@ -1599,7 +1599,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, +> #else +> "-netdev tap,id=str[,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile]\n" +> " [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n" +> - " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n]\n" +> + " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,vhostlog=file|dir][,queues=n]\n" +> " [,poll-us=n]\n" +> " configure a host TAP network backend with ID 'str'\n" +> " connected to a bridge (default=" DEFAULT_BRIDGE_INTERFACE ")\n" +> @@ -1618,6 +1618,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, +> " use vhost=on to enable experimental in kernel accelerator\n" +> " (only has effect for virtio guests which use MSIX)\n" +> " use vhostforce=on to force vhost on for non-MSIX virtio guests\n" +> + " use 'vhostlog=file|dir' file or directory for vhost backend log\n" +> " use 'vhostfd=h' to connect to an already opened vhost net device\n" +> " use 'vhostfds=x:y:...:z to connect to multiple already opened vhost net devices\n" +> " use 'queues=n' to specify the number of queues to be created for multiqueue TAP\n" +> diff --git a/util/Makefile.objs b/util/Makefile.objs +> index 36c7dcc..69bb27a 100644 +> --- a/util/Makefile.objs +> +++ b/util/Makefile.objs +> @@ -3,6 +3,7 @@ util-obj-y += bufferiszero.o +> util-obj-$(CONFIG_POSIX) += compatfd.o +> util-obj-$(CONFIG_POSIX) += event_notifier-posix.o +> util-obj-$(CONFIG_POSIX) += mmap-alloc.o +> +util-obj-$(CONFIG_POSIX) += mmap-file.o +> util-obj-$(CONFIG_POSIX) += oslib-posix.o +> util-obj-$(CONFIG_POSIX) += qemu-openpty.o +> util-obj-$(CONFIG_POSIX) += qemu-thread-posix.o +> diff --git a/util/mmap-file.c b/util/mmap-file.c +> new file mode 100644 +> index 0000000..ce778cf +> --- /dev/null +> +++ b/util/mmap-file.c +> @@ -0,0 +1,153 @@ +> +/* +> + * Support for file backed by mmaped host memory. +> + * +> + * Authors: +> + * Rafael David Tinoco <email address hidden> +> + * +> + * This work is licensed under the terms of the GNU GPL, version 2 or +> + * later. See the COPYING file in the top-level directory. +> + */ +> + +> +#include "qemu/osdep.h" +> +#include "qemu/mmap-file.h" +> + +> +static char *qemu_mmap_rand_name(void) +> +{ +> + char *name; +> + GRand *rsufix; +> + guint32 sufix; +> + +> + rsufix = g_rand_new(); +> + sufix = g_rand_int(rsufix); +> + g_free(rsufix); +> + name = g_strdup_printf("mmap-%u", sufix); +> + +> + return name; +> +} +> + +> +static inline void qemu_mmap_rand_name_free(char *str) +> +{ +> + g_free(str); +> +} +> + +> +static bool qemu_mmap_is(const char *path, mode_t what) +> +{ +> + struct stat s; +> + +> + memset(&s, 0, sizeof(struct stat)); +> + if (stat(path, &s)) { +> + perror("stat"); +> + goto negative; +> + } +> + +> + if ((s.st_mode & S_IFMT) == what) { +> + return true; +> + } +> + +> +negative: +> + return false; +> +} +> + +> +static inline bool qemu_mmap_is_file(const char *path) +> +{ +> + return qemu_mmap_is(path, S_IFREG); +> +} +> + +> +static inline bool qemu_mmap_is_dir(const char *path) +> +{ +> + return qemu_mmap_is(path, S_IFDIR); +> +} +> + +> +static void *qemu_mmap_alloc_file(const char *filepath, size_t size, int *fd) +> +{ +> + void *ptr; +> + int mfd = -1; +> + +> + *fd = -1; +> + +> + mfd = open(filepath, O_CREAT | O_EXCL | O_RDWR, S_IRUSR | S_IWUSR); +> + if (mfd == -1) { +> + perror("open"); +> + return NULL; +> + } +> + +> + unlink(filepath); +> + +> + if (ftruncate(mfd, size) == -1) { +> + perror("ftruncate"); +> + close(mfd); +> + return NULL; +> + } +> + +> + ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); +> + if (ptr == MAP_FAILED) { +> + perror("mmap"); +> + close(mfd); +> + return NULL; +> + } +> + +> + *fd = mfd; +> + return ptr; +> +} +> + +> +static void *qemu_mmap_alloc_dir(const char *dirpath, size_t size, int *fd) +> +{ +> + void *ptr; +> + char *file, *rand, *tmp, *dir2use = NULL; +> + +> + if (dirpath && !qemu_mmap_is_dir(dirpath)) { +> + return NULL; +> + } +> + +> + tmp = (char *) g_get_tmp_dir(); +> + dir2use = dirpath ? (char *) dirpath : tmp; +> + rand = qemu_mmap_rand_name(); +> + file = g_strdup_printf("%s/%s", dir2use, rand); +> + ptr = qemu_mmap_alloc_file(file, size, fd); +> + g_free(tmp); +> + qemu_mmap_rand_name_free(rand); +> + +> + return ptr; +> +} +> + +> +/* +> + * "path" can be: +> + * +> + * filename = full path for the file to back mmap +> + * dir path = full dir path where to create random file for mmap +> + * null = will use <tmpdir> to create random file for mmap +> + */ +> +void *qemu_mmap_alloc(const char *path, size_t size, int *fd) +> +{ +> + if (!path || qemu_mmap_is_dir(path)) { +> + return qemu_mmap_alloc_dir(path, size, fd); +> + } +> + +> + return qemu_mmap_alloc_file(path, size, fd); +> +} +> + +> +void qemu_mmap_free(void *ptr, size_t size, int fd) +> +{ +> + if (ptr) { +> + munmap(ptr, size); +> + } +> + +> + if (fd != -1) { +> + close(fd); +> + } +> +} +> + +> +bool qemu_mmap_check(const char *path) +> +{ +> + void *ptr; +> + int fd = -1; +> + bool r = true; +> + +> + ptr = qemu_mmap_alloc(path, 4096, &fd); +> + if (!ptr) { +> + r = false; +> + } +> + qemu_mmap_free(ptr, 4096, fd); +> + +> + return r == true ? true : false; +> +} +> -- +> 2.9.3 + + +On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <email address hidden> wrote: +> +> On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +> > Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> > check if memfd would succeed. It is better if this blocker first +> > checks if vhost backend requires shared log. This will avoid a +> > situation where a blocker is added inappropriately (e.g. shared +> > log allocation fails when vhost backend doesn't support it). +> +> Sounds like a bugfix but I'm not sure. Can this part be split +> out in a patch by itself? + +Already sent some days ago (and pointed by Marc today). + +> > Commit: 35f9b6e added a fallback mechanism for systems not supporting +> > memfd_create syscall (started being supported since 3.17). +> > +> > Backporting memfd_create might not be accepted for distros relying +> > on older kernels. Nowadays there is no way for security driver +> > to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> > +> > Also, because vhost log file descriptors can be passed to other +> > processes, after discussion, we thought it is best to back mmap by +> > using files that can be placed into a specific directory: this commit +> > creates "vhostlog" argv parameter for such purpose. This will allow +> > security drivers to operate on those files appropriately. +> > +> > Argv examples: +> > +> > -netdev tap,id=net0,vhost=on +> > -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> > -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> > +> > For vhost backends supporting shared logs, if vhostlog is non-existent, +> > or a directory, random files are going to be created in the specified +> > directory (or, for non-existent, in tmpdir). If vhostlog is specified, +> > the filepath is always used when allocating vhost log files. +> +> When vhostlog is not specified, can we just use memfd as we did? +> + +This was my approach on a "pastebin" example before this patch (in the +discussion thread we had). Problem goes back to when vhost log file +descriptor is shared with some vhost-user implementation - like the +interface allows to - and the security driver labelling issue. IMO, +yes, we could let vhostlog to specify a log file, and, if not +specified, assume memfd is ok to be used. + +Please let me know if you - and Marc - want me to keep using memfd. +I'll create the mmap-file tests and files in a different commit, like +Marc has asked for, and will propose the patch again by the end of +this week. + + +On Mon, Oct 31, 2016 at 08:35:33AM -0200, Rafael David Tinoco wrote: +> On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <email address hidden> wrote: +> > +> > On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +> > > Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> > > check if memfd would succeed. It is better if this blocker first +> > > checks if vhost backend requires shared log. This will avoid a +> > > situation where a blocker is added inappropriately (e.g. shared +> > > log allocation fails when vhost backend doesn't support it). +> > +> > Sounds like a bugfix but I'm not sure. Can this part be split +> > out in a patch by itself? +> +> Already sent some days ago (and pointed by Marc today). +> +> > > Commit: 35f9b6e added a fallback mechanism for systems not supporting +> > > memfd_create syscall (started being supported since 3.17). +> > > +> > > Backporting memfd_create might not be accepted for distros relying +> > > on older kernels. Nowadays there is no way for security driver +> > > to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> > > +> > > Also, because vhost log file descriptors can be passed to other +> > > processes, after discussion, we thought it is best to back mmap by +> > > using files that can be placed into a specific directory: this commit +> > > creates "vhostlog" argv parameter for such purpose. This will allow +> > > security drivers to operate on those files appropriately. +> > > +> > > Argv examples: +> > > +> > > -netdev tap,id=net0,vhost=on +> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> > > +> > > For vhost backends supporting shared logs, if vhostlog is non-existent, +> > > or a directory, random files are going to be created in the specified +> > > directory (or, for non-existent, in tmpdir). If vhostlog is specified, +> > > the filepath is always used when allocating vhost log files. +> > +> > When vhostlog is not specified, can we just use memfd as we did? +> > +> +> This was my approach on a "pastebin" example before this patch (in the +> discussion thread we had). Problem goes back to when vhost log file +> descriptor is shared with some vhost-user implementation - like the +> interface allows to - and the security driver labelling issue. IMO, +> yes, we could let vhostlog to specify a log file, and, if not +> specified, assume memfd is ok to be used. +> +> Please let me know if you - and Marc - want me to keep using memfd. +> I'll create the mmap-file tests and files in a different commit, like +> Marc has asked for, and will propose the patch again by the end of +> this week. + +I think that the best approach is to allow passing in the fd, +not the file path. If not passed, use memfd. + +-- +MST + + +Hello Michael, André, + +Could you do a quick review before a final submission ? + +http://paste.ubuntu.com/23446279/ + +- I split the commits into 1) bugfix, 2) new util with test, 3) vhostlog + +The unit test is testing passing fds between 2 processes and asserting +contents of mmap buffer coming from the "vhostlog" util (mmap-file). + +Your final comment on the "vhostlog" was: + +>> Argv examples: +>> +>> -netdev tap,id=net0,vhost=on +>> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +>> -netdev tap,id=net0,vhost=on,vhostlog=/tmp + +(André) > Could it be only a filename? This would simplify testing. +(Michael) > When vhostlog is not specified, can we just use memfd as we did? + +I'm going to change this to: + +1 - if vhostlog is not provided shared log can't be used. Use memfd. + +2 - for shared logs, vhostlog has to be provided as a "file" ? + +Should i keep vhostlog being a directory also ? (i know we are unlinking the +file so might not be needed BUT a static file might have a race condition in +between different instances and providing a directory - that creates random +files on it - might be better approach). + +Is there anything else ? + +Thank you + +Rafael Tinoco + +On Mon, Oct 31, 2016 at 8:30 PM, Michael S. Tsirkin <email address hidden> wrote: +> On Mon, Oct 31, 2016 at 08:35:33AM -0200, Rafael David Tinoco wrote: +>> On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <email address hidden> wrote: +>> > +>> > On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +>> > > Commit 31190ed7 added a migration blocker in vhost_dev_init() to +>> > > check if memfd would succeed. It is better if this blocker first +>> > > checks if vhost backend requires shared log. This will avoid a +>> > > situation where a blocker is added inappropriately (e.g. shared +>> > > log allocation fails when vhost backend doesn't support it). +>> > +>> > Sounds like a bugfix but I'm not sure. Can this part be split +>> > out in a patch by itself? +>> +>> Already sent some days ago (and pointed by Marc today). +>> +>> > > Commit: 35f9b6e added a fallback mechanism for systems not supporting +>> > > memfd_create syscall (started being supported since 3.17). +>> > > +>> > > Backporting memfd_create might not be accepted for distros relying +>> > > on older kernels. Nowadays there is no way for security driver +>> > > to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +>> > > +>> > > Also, because vhost log file descriptors can be passed to other +>> > > processes, after discussion, we thought it is best to back mmap by +>> > > using files that can be placed into a specific directory: this commit +>> > > creates "vhostlog" argv parameter for such purpose. This will allow +>> > > security drivers to operate on those files appropriately. +>> > > +>> > > Argv examples: +>> > > +>> > > -netdev tap,id=net0,vhost=on +>> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +>> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp +>> > > +>> > > For vhost backends supporting shared logs, if vhostlog is non-existent, +>> > > or a directory, random files are going to be created in the specified +>> > > directory (or, for non-existent, in tmpdir). If vhostlog is specified, +>> > > the filepath is always used when allocating vhost log files. +>> > +>> > When vhostlog is not specified, can we just use memfd as we did? +>> > +>> +>> This was my approach on a "pastebin" example before this patch (in the +>> discussion thread we had). Problem goes back to when vhost log file +>> descriptor is shared with some vhost-user implementation - like the +>> interface allows to - and the security driver labelling issue. IMO, +>> yes, we could let vhostlog to specify a log file, and, if not +>> specified, assume memfd is ok to be used. +>> +>> Please let me know if you - and Marc - want me to keep using memfd. +>> I'll create the mmap-file tests and files in a different commit, like +>> Marc has asked for, and will propose the patch again by the end of +>> this week. +> +> I think that the best approach is to allow passing in the fd, +> not the file path. If not passed, use memfd. +> +> -- +> MST + + +Hi + +On Tue, Nov 8, 2016 at 4:49 PM Rafael David Tinoco < +<email address hidden>> wrote: + +> Hello Michael, André, +> +> Could you do a quick review before a final submission ? +> +> http://paste.ubuntu.com/23446279/ +> +> - I split the commits into 1) bugfix, 2) new util with test, 3) vhostlog +> +> The unit test is testing passing fds between 2 processes and asserting +> contents of mmap buffer coming from the "vhostlog" util (mmap-file). +> +> Your final comment on the "vhostlog" was: +> +> >> Argv examples: +> >> +> >> -netdev tap,id=net0,vhost=on +> >> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> >> -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> +> (André) > Could it be only a filename? This would simplify testing. +> (Michael) > When vhostlog is not specified, can we just use memfd as we +> did? +> +> +Michael said: +https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg08197.html +I think that the best approach is to allow passing in the fd, not the file +path. If not passed, use memfd. + +I do agree :) + +I'm going to change this to: +> +> 1 - if vhostlog is not provided shared log can't be used. Use memfd. +> +> 2 - for shared logs, vhostlog has to be provided as a "file" ? +> +> Should i keep vhostlog being a directory also ? (i know we are unlinking +> the +> file so might not be needed BUT a static file might have a race condition +> in +> between different instances and providing a directory - that creates random +> files on it - might be better approach). +> +> Is there anything else ? +> + +Do we really need to give a path? (pass fd with -add-fd/qmp add-fd) + +Thank you +> +> Rafael Tinoco +> +> On Mon, Oct 31, 2016 at 8:30 PM, Michael S. Tsirkin <email address hidden> +> wrote: +> > On Mon, Oct 31, 2016 at 08:35:33AM -0200, Rafael David Tinoco wrote: +> >> On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <email address hidden> +> wrote: +> >> > +> >> > On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +> >> > > Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> >> > > check if memfd would succeed. It is better if this blocker first +> >> > > checks if vhost backend requires shared log. This will avoid a +> >> > > situation where a blocker is added inappropriately (e.g. shared +> >> > > log allocation fails when vhost backend doesn't support it). +> >> > +> >> > Sounds like a bugfix but I'm not sure. Can this part be split +> >> > out in a patch by itself? +> >> +> >> Already sent some days ago (and pointed by Marc today). +> >> +> >> > > Commit: 35f9b6e added a fallback mechanism for systems not +> supporting +> >> > > memfd_create syscall (started being supported since 3.17). +> >> > > +> >> > > Backporting memfd_create might not be accepted for distros relying +> >> > > on older kernels. Nowadays there is no way for security driver +> >> > > to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> >> > > +> >> > > Also, because vhost log file descriptors can be passed to other +> >> > > processes, after discussion, we thought it is best to back mmap by +> >> > > using files that can be placed into a specific directory: this +> commit +> >> > > creates "vhostlog" argv parameter for such purpose. This will allow +> >> > > security drivers to operate on those files appropriately. +> >> > > +> >> > > Argv examples: +> >> > > +> >> > > -netdev tap,id=net0,vhost=on +> >> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> >> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> >> > > +> >> > > For vhost backends supporting shared logs, if vhostlog is +> non-existent, +> >> > > or a directory, random files are going to be created in the +> specified +> >> > > directory (or, for non-existent, in tmpdir). If vhostlog is +> specified, +> >> > > the filepath is always used when allocating vhost log files. +> >> > +> >> > When vhostlog is not specified, can we just use memfd as we did? +> >> > +> >> +> >> This was my approach on a "pastebin" example before this patch (in the +> >> discussion thread we had). Problem goes back to when vhost log file +> >> descriptor is shared with some vhost-user implementation - like the +> >> interface allows to - and the security driver labelling issue. IMO, +> >> yes, we could let vhostlog to specify a log file, and, if not +> >> specified, assume memfd is ok to be used. +> >> +> >> Please let me know if you - and Marc - want me to keep using memfd. +> >> I'll create the mmap-file tests and files in a different commit, like +> >> Marc has asked for, and will propose the patch again by the end of +> >> this week. +> > +> > I think that the best approach is to allow passing in the fd, +> > not the file path. If not passed, use memfd. +> > +> > -- +> > MST +> +> -- +Marc-André Lureau + + +Hello, + +> On Tue, Nov 8, 2016 at 4:49 PM Rafael David Tinoco <email address hidden> wrote: +> Hello Michael, André, +> +> Could you do a quick review before a final submission ? +> +> http://paste.ubuntu.com/23446279/ +> ... +> (André) > Could it be only a filename? This would simplify testing. +> (Michael) > When vhostlog is not specified, can we just use memfd as we did? +> +> Michael said: https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg08197.html +> I think that the best approach is to allow passing in the fd, not the file path. If not passed, use memfd. + +Missed this one. + +> I do agree :) + +Sounds good. I see that the new approach is to let the managing library to create the files and just pass the file descriptors, this way security rules are applied to library itself and not to qemu processes. + +> Do we really need to give a path? (pass fd with -add-fd/qmp add-fd) + +I guess not. So, for shared logs: + +- vhostlogfd has to be provided. +- if vhostlogfd is not provided, use memfd. +(we don't want writes in /tmp, should i remove fallback mechanism from memfd logic) +- if memfd fails, log can't be shared/created and there is a migration blocker. + +André, Michael, + +I'll work on that and get the patches soon, meanwhile, could u push: + +- "vhost: migration blocker only if shared log is use" + +so I can backport it to Debian ? + +Thank you, +-Rafael Tinoco + +For Ubuntu Xenial (Mitaka), Yakkety (Newton), Zesty: Commit 0d34fbabc1 fixes the issue for vhost-net kernel. Vhost-net kernel doesn't use shared log so the verification is not used and apparmor profiles won't block the live migration. With customers using vhost-user that might still cause migration problems, but, likely, those are the vast minority. + +commit 0d34fbabc13891da41582b0823867dc5733fffef +Author: Rafael David Tinoco <email address hidden> +Date: Mon Oct 24 15:35:03 2016 +0000 + + vhost: migration blocker only if shared log is used + + Commit 31190ed7 added a migration blocker in vhost_dev_init() to + check if memfd would succeed. It is better if this blocker first + checks if vhost backend requires shared log. This will avoid a + situation where a blocker is added inappropriately (e.g. shared + log allocation fails when vhost backend doesn't support it). + + Signed-off-by: Rafael David Tinoco <email address hidden> + Reviewed-by: Marc-André Lureau <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + +diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +index 131f164..25bf67f 100644 +--- a/hw/virtio/vhost.c ++++ b/hw/virtio/vhost.c +@@ -1122,7 +1122,7 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { + error_setg(&hdev->migration_blocker, + "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +- } else if (!qemu_memfd_check()) { ++ } else if (vhost_dev_log_is_shared(hdev) && !qemu_memfd_check()) { + error_setg(&hdev->migration_blocker, + "Migration disabled: failed to allocate shared memory"); + } + +The "final" fix for upstream fix is being finished by me, but, might not be suitable for SRU since it will add features in qemu (and likely to libvirt) in order for the vhost log file to be passed (by using an already opened file descriptor). This will require changes in libvirt and nova-compute but this change will, finally, allow security driver to apply rules to vhost log file for shared logs (mostly for vhost-user drivers). + +On Fri, Nov 18, 2016 at 11:21 AM, Rafael David Tinoco < +<email address hidden>> wrote: + +> With customers using vhost-user that might +> still cause migration problems, but, likely, those are the vast +> minority. +> + +It is and has migration issues in general atm anyway - see: +https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg03026.html +https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg03223.html + +So that needs more work and is not in your current scope IMHO. + + +Thanks Christian, + +Then I'll finish this SRU first. Will work in the vhost mmap log file right after. + + + +Took some more time here because of LP: #1621269. + +Right now Zesty is behind Yakkety because of a Security Update. Not sure you need me to attach a debdiff for Zesty as well. Let me know. + +On Tue, Nov 22, 2016 at 1:02 PM, Rafael David Tinoco < +<email address hidden>> wrote: + +> Right now Zesty is behind Yakkety because of a Security Update. Not sure +> you need me to attach a debdiff for Zesty as well. Let me know. +> + +Arr - bad timing It got an upload about 5 minutes ago. +So yes a Zesty debdiff would be nice. + +-- +Christian Ehrhardt +Software Engineer, Ubuntu Server +Canonical Ltd + + + + +Thanks Rafael - the upstream work on this is excellent! + +I already built all those fine and I'm now looking into some regression checks before considering/doing an upload to Dev-Release & SRU-queue + +Some other stages of my extra tests are currently WIP, but those that work worked fine on the ppa I built of your debdiffs. + +That covers: +- migration with various workloads +- different types of migrations (live, offline, postcopy) +- upgrading onto the new qemu version +- migration into the upgraded version + +I'll attach the log and upload your changes, thanks for your work. +I see you already set the SRU Teamplate for the SRU Team to review then - thanks. + + + +Uploaded into Zesty - per SRU policy (and experience that always something happens at the last minute at LP build/tests) waiting with the SRU uploads until that fully migrated. + +This bug was fixed in the package qemu - 1:2.6.1+dfsg-0ubuntu7 + +--------------- +qemu (1:2.6.1+dfsg-0ubuntu7) zesty; urgency=medium + + [ Rafael David Tinoco ] + * Fixed wrong migration blocker when vhost is used (LP: #1626972) + - d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch + + -- Christian Ehrhardt <email address hidden> Tue, 22 Nov 2016 13:45:52 +0100 + +Ok, update into Zesty has passed and you already supplied the SRU Template. +Uploaded to Xenial and Yakkety queues for the SRU Team to consider your Fix. + +Hello Rafael, or anyone else affected, + +Accepted qemu into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu10.7 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 to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Commit 0d34fbabc13 is upstream, so setting this to "Fix committed", too. + + +This bug was fixed in the package qemu - 1:2.6.1+dfsg-0ubuntu7~cloud0 +--------------- + + qemu (1:2.6.1+dfsg-0ubuntu7~cloud0) xenial-ocata; urgency=medium + . + * New update for the Ubuntu Cloud Archive. + . + qemu (1:2.6.1+dfsg-0ubuntu7) zesty; urgency=medium + . + [ Rafael David Tinoco ] + * Fixed wrong migration blocker when vhost is used (LP: #1626972) + - d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch + + +Hello Rafael, or anyone else affected, + +Accepted qemu into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.6.1+dfsg-0ubuntu5.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 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 to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Hi all, + +I am facing this issue too, and although I can confirm the patch can be easily backported to Trusty (we run Mitaka on Trusty), some of our customers have VMs started with the old qemu and I cannot live migrate anymore or update qemu without stopping and starting the VM. + +Do you have any suggestion on how to allow the live migration of VMs currently running with qemu pre-patch and kernel 3.13? + +Thank you in advance + +Hello Antonio (@arcimboldo) + +The fix only makes sense for newer QEMUs (>= Xenial, like the one from Mitaka Ubuntu Cloud Archive). + +OBS: + +The "migration check" is done in VHOST initialization functions when the devices are virtually attached to the virtual machine. If you are using kernel 3.13 and have apparmor enabled, then all the running instances have the "migration blocker" ON - because of this buggy migration check - and won't be able to live migration. + +Unfortunately there is a "in-memory" linked list telling qemu that is has a blocker (with the reason). This blocker was added during instance startup and will be checked/used only when instance is live-migrated. + +Check this: http://pastebin.ubuntu.com/23517175/ + +If you started the instance in a host not running apparmor (or not having libvirt profile loaded, for example) it won't block the creation of /tmp/memfd-XXX files during instance initialization. That won't trigger the "blocker flag" inside the running program and, if/when needed, the live migration will be able to occur. + +This means that, after installing the new package, if you're using apparmor, yes, you would have to RESTART running instances that were affected by this bug in order to live migrating them. Sorry for the bad news! Even if you remove the apparmor rules, the migration blocker is already set. + +Hacking your process virtual memory would jeopardize the contents of the virtual memory (could be catastrophic specially for a virtual machine). + + +@jamespage, @cpaelzer, + +I'll verify this fix in couple of days so it can be released. + +Thank you! + +Rafael + +Xenial Verification (with 3.13 kernel from Trusty since a <= 3.17 kernel is needed). This verifies that Ubuntu Cloud Archive repositories will be alright with this new packages (from Xenial / Yakkety). + +## CURRENT + +inaddy@(xkvm01):~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:2.5+dfsg-5ubuntu10.6 + Candidate: 1:2.5+dfsg-5ubuntu10.6 + +xkvm01 (sender): + +Jan 11 01:07:54 xkvm01 kernel: type=1400 audit(1484104074.014:13): apparmor="DENIED" operation="mknod" profile="libvirt-7cdcb6c0-f85e-4639-912b-c785bd5992d9" name="/tmp/memfd-Jh5UhR" pid=2535 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=112 ouid=112 + +$ sudo virsh migrate --live guest qemu+ssh://xkvm02/system +error: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory + +xkvm02 (receiver): + +Jan 11 01:08:23 xkvm02 kernel: type=1400 audit(1484104103.888:53): apparmor="DENIED" operation="mknod" profile="libvirt-7cdcb6c0-f85e-4639-912b-c785bd5992d9" name="/tmp/memfd-fc9rij" pid=2000 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=112 ouid=112 + +OBS: The check was being done in the wrong place AND situation, like I showed in this bug. + +## PROPOSED + + +inaddy@(xkvm01):~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:2.5+dfsg-5ubuntu10.7 + Candidate: 1:2.5+dfsg-5ubuntu10.7 + +xkvm01 (sender): + +<nothing related to /tmp/memfd> + +xkvm02 (receiver): + +inaddy@(xkvm02):~$ virsh list + Id Name State +---------------------------------------------------- + 1 guest running + +<nothing related to /tmp/memfd> + +Its all good. + +verification-xenial-done + +Yakkety Verification (with 3.13 kernel from Trusty since a <= 3.17 kernel is needed). This verifies that Ubuntu Cloud Archive repositories will be alright with this new packages (from Xenial / Yakkety). + +## CURRENT + +inaddy@(ykvm01):~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:2.6.1+dfsg-0ubuntu5.1 + Candidate: 1:2.6.1+dfsg-0ubuntu5.1 + +ykvm01 (sender): + +Jan 11 11:34:35 ykvm01 kernel: type=1400 audit(1484141675.962:53): apparmor="DENIED" operation="mknod" profile="libvirt-7cdcb6c0-f85e-4639-912b-c785bd5992d9" name="/tmp/memfd-bF8new" pid=1934 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=111 ouid=111 + +inaddy@(ykvm01):~$ sudo virsh migrate --live guest qemu+ssh://ykvm02/system +error: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory + +ykvm02 (receiver): + +Jan 11 11:39:31 ykvm02 kernel: type=1400 audit(1484141971.526:53): apparmor="DENIED" operation="mknod" profile="libvirt-7cdcb6c0-f85e-4639-912b-c785bd5992d9" name="/tmp/memfd-JZ6L9T" pid=2177 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=111 ouid=111 + +OBS: The check was being done in the wrong place AND situation, like I showed in this bug. + + + +## PROPOSED + +inaddy@(ykvm01):~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:2.6.1+dfsg-0ubuntu5.2 + Candidate: 1:2.6.1+dfsg-0ubuntu5.2 + +ykvm01 (sender): + +<nothing related to /tmp/memfd> + +ykvm02 (receiver): + +inaddy@(ykvm02):~$ virsh list + Id Name State +---------------------------------------------------- + 1 guest running + +<nothing related to /tmp/memfd> + +Its all good. + +verification-yakkety-done + +Commit 0d34fbabc13 has been released with QEMU v2.8 + +This bug was fixed in the package qemu - 1:2.6.1+dfsg-0ubuntu5.2 + +--------------- +qemu (1:2.6.1+dfsg-0ubuntu5.2) yakkety; urgency=medium + + [ Rafael David Tinoco ] + * Fixed wrong migration blocker when vhost is used (LP: #1626972) + - d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch + + -- Christian Ehrhardt <email address hidden> Tue, 22 Nov 2016 13:45:46 +0100 + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been 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. + +Ping - we have the next fix for Xenial in the queue - all others are released now, has this one "baked" enough for Xenial SRU to migrate? + +For me we had enough tests already. Upstream development/tests, Zesty, Yakkety. Christian, could you please move Xenial for me ? I have some end users waiting for this. Thank you very much. + +On Tue, Jan 24, 2017 at 1:52 AM, Rafael David Tinoco < +<email address hidden>> wrote: + +> Christian, could you please move Xenial for me ? I have some +> end users waiting for this. Thank you very much. +> + +I can't - IIRC that is up to the SRU Team, I pinged the #ubuntu-release +channel if one could take a look. +You could do so again today if you want. + + +Thanks Christian! Will do!! + +This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.7 + +--------------- +qemu (1:2.5+dfsg-5ubuntu10.7) xenial; urgency=medium + + [ Rafael David Tinoco ] + * Fixed wrong migration blocker when vhost is used (LP: #1626972) + - d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch + + -- Christian Ehrhardt <email address hidden> Tue, 22 Nov 2016 13:45:39 +0100 + +For Mitaka, this bug will be included in UCA together with the fix for: + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1656480 + +When it becomes available. + diff --git a/results/classifier/zero-shot/108/none/1634 b/results/classifier/zero-shot/108/none/1634 new file mode 100644 index 000000000..0a9a56b19 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1634 @@ -0,0 +1,33 @@ +graphic: 0.561 +device: 0.370 +other: 0.346 +semantic: 0.234 +permissions: 0.130 +PID: 0.108 +performance: 0.103 +files: 0.091 +debug: 0.088 +network: 0.087 +boot: 0.066 +vnc: 0.060 +socket: 0.046 +KVM: 0.019 + +[8.0.0] Broken snapshot replay support on PowerPC +Description of problem: +QEMU 8.0.0 can no longer replay snapshots on PowerPC e500mc (Book-E) architecture. The issue is caused by https://gitlab.com/qemu-project/qemu/-/commit/c4b075318eb1e87de5fc942e6b987694a0e677e1, reverting this commit solves the issue. +Steps to reproduce: +1. Run bare metal example from the attachment with the first command-line to create snapshot. +2. Run bare metal example from the attachment with the second command-line to replay snapshot. +Additional information: +Any e500mc example would do really. I was unable to find a prebuilt Linux distribution, thus just wrote a minimal sample that prints hello world to UART: [ppc-e500.zip](/uploads/f9328c4b8355a92877d784661aa69fa4/ppc-e500.zip) + +Log output: + +``` +% qemu-system-ppc -cpu e500mc -M ppce500 -m 128M -net none -icount 1,rr=record,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr -display none -kernel hello.elf -serial stdio +Hello world +qemu-system-ppc: terminating on signal 2 from pid 4505 (<unknown process>) +% qemu-system-ppc -cpu e500mc -M ppce500 -m 128M -net none -icount 1,rr=replay,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr -display none -kernel hello.elf -serial stdio +qemu-system-ppc: Missing random event in the replay log +``` diff --git a/results/classifier/zero-shot/108/none/1634069 b/results/classifier/zero-shot/108/none/1634069 new file mode 100644 index 000000000..123efcc38 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1634069 @@ -0,0 +1,35 @@ +device: 0.575 +graphic: 0.554 +other: 0.500 +semantic: 0.426 +PID: 0.412 +performance: 0.396 +network: 0.380 +permissions: 0.358 +vnc: 0.330 +files: 0.329 +KVM: 0.319 +socket: 0.318 +debug: 0.309 +boot: 0.221 + +Exclude keys from grab + +Feature request: pressing every time a shortcut to release grab for switching windows/desktops is pretty annoying, especially for users of tiling WMs. + +QEMU have to have a way to specify keys or shortcuts (possibly something like "everything with the specified modifier key"), which would not be intercepted. + +Alternatively/additionally it would be nice to be able to disable keys grabbing at all. + +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/138 + + diff --git a/results/classifier/zero-shot/108/none/1635339 b/results/classifier/zero-shot/108/none/1635339 new file mode 100644 index 000000000..4eb9794f7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1635339 @@ -0,0 +1,828 @@ +KVM: 0.588 +vnc: 0.506 +other: 0.423 +boot: 0.380 +device: 0.378 +debug: 0.357 +performance: 0.350 +permissions: 0.334 +network: 0.314 +semantic: 0.302 +socket: 0.287 +graphic: 0.282 +PID: 0.279 +files: 0.269 + +qxl_pre_save assertion failure on vm "save" + +When I try and save my Windows 10 VM, I see an assertion failure, and the machine is shut down. + +I see the following in the log: + +main_channel_handle_parsed: agent start +qemu-system-x86_64: /build/qemu-Zwynhi/qemu-2.5+dfsg/hw/display/qxl.c:2101: qxl_pre_save: Assertion `d->last_release_offset < d->vga.vram_size' failed. +2016-10-20 11:52:42.713+0000: shutting down + +Please let me know what other information would be relevant! + +Hmm docmax on #qemu just complained about a similar error; although they were on win2016, and using qemu-2.7 and the latest git versions, and that assert has been in there for years. + +Can you please add the full qemu command line you're using, and the version of the spice/qxl drivers you're using inside the windows VM. + + +QXL driver version is 17.54.59.923 + +Commandline (git compiled today) is: + +/usr/sbin/qemu-system-x86_64 -name guest=dc,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-dc/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Haswell-noTSX,+vme,+ds,+acpi,+ss,+ht,+tm,+pbe,+dtes64,+monitor,+ds_cpl,+vmx,+est,+tm2,+xtpr,+pdcm,+osxsave,+f16c,+rdrand,+arat,+tsc_adjust,+xsaveopt,+pdpe1gb,+abm -drive file=/usr/share/ovmf/x64/ovmf_code_x64.bin,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/dc_VARS.fd,if=pflash,format=raw,unit=1 -m 2048 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 647fd6b2-9a88-4219-af46-052f68a539a5 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-dc/monitor.sock,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=/mnt/shared/server/root/var/lib/libvirt/images/hdd/dc.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:58:ce:4e,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 -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=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=0x8 -msg timestamp=on + +I tried other QXL drivers: 22.33.46.473. +These work (but have a older date: 2015-07-28. + +17.54.59.923 have the date 2016-04-21. +I got them from this package: + +http://depot.flexvdi.com/guest-tools/flexvdi-guest-tools-2.2.11.iso + +Those provide something, which lets my window resize freely. + +I'm running into this issue as well: +Arch Linux +Qemu 2.8.0 +spice guest tools: 0.132 +QXL driver version (as reported by Windows Device Manager): 10.0.0.15000 + +Everything else works great. It would save me a lot of rebooting if this could get fixed. +If there is anything I can do or try, I'll be glad to help. + +Relevant log of VM boot and crash on selecting suspend action in virt-manager: + +2017-04-06 16:59:24.681+0000: starting up libvirt version: 3.1.0, qemu version: 2.8.0, hostname: arch-vaio.localdomain +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name guest=Windows,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-9-Windows/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu core2duo,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 2048 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=1 -uuid f14684d3-5f81-4743-8512-e516d85ca2c9 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-9-Windows/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 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=/mnt/media/Qemu/windows10.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/usr/share/spice-guest-tools/spice-guest-tools.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 -netdev user,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:44:08:31,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=input2,bus=usb.0,port=3 -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=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=0x8 -msg timestamp=on +char device redirected to /dev/pts/6 (label charserial0) +main_channel_link: add main channel client +red_dispatcher_set_cursor_peer: +inputs_connect: inputs channel client create +main_channel_handle_parsed: agent start +ehci warning: guest updated active QH +qemu-system-x86_64: /build/qemu/src/qemu-2.8.0/hw/display/qxl.c:2173: qxl_pre_save: Assertion `d->last_release_offset < d->vga.vram_size' failed. +2017-04-06 17:00:32.819+0000: shutting down, reason=crashed + +I can see a bunch of similar looking failures in Fedora's automatic backtrace stats system + +I put my money on that one: + +https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa + +commit f6e099db39e7d0787f294d5fd0dce328b5210faa +Author: Sameeh Jubran <email address hidden> +Date: Sun Sep 11 16:05:24 2016 +0300 + + Use the second bar (VRAM) for qxl command buffer. + + Based on a patch by Sandy Stutsman <email address hidden> + + Signed-off-by: Sameeh Jubran <email address hidden> + Acked-by: Frediano Ziglio <email address hidden> + + + +Crash reproduced immediately after setting up a win10 VM with qxl driver 10.0.0.15000. + +Gerd, are you looking into fixing it? Is it acceptable to crash qemu if the driver is faulty? + +damn launchpad, wrong bug and I can't change it back. Please someone move it back to New/Confirmed + +Well. qxl commands are expected to live in bar 0 (same bar where the rings are too). vram bar was added as surface storage. + +Now the windows drivers started to us vram for qxl commands. Problem is we simply can't live-migrate such a guest. At least not without changing the vmstate format. Which isn't something I would attempt just a few days before release. + +We can't throw an error in qxl_pre_save either (and fail migration instead of aborting). + +I don't see an easy way out for 2.9. + +Long term options are (a) revert the driver change, and probably add some checks to qxl to make sure guests don't use vram for commands, or (b) extend qxl vmstate so we can handle that case. + +An untested hack that might fail cleaner might be: + + error_report("Broken driver ..... migration failed"); + qemu_file_set_error(migrate_get_current()->to_dst_file, -EINVAL); + +(untested, probably needs checking it works with savevm). + +I must go around and add a return value to pre_save(). + +We probably also need to make sure some migration testing gets added to the driver dev + +Not sure we want a failure mode for pre_save(). + +If we go for option (a) (from comment 9), I'd add a check when reading the commands from the ring, not at migration time, so we don't run enter a state where pre_save() can fail in the first place. Because that will break the windows drivers we might add a warning only for 2.9, then for 2.10 raise an error irq. Something like this: + +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -639,6 +639,24 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size)) { ++#if 1 ++ /* temporary, for 2.9 */ ++ static int once; ++ if (!once) { ++ fprintf(stderr, "qxl: guest bug: command not in ram bar, " ++ "guest not migratable\n"); ++ once = true; ++ } ++#else ++ qxl_set_guest_bug(qxl, "command not in ram bar"); ++ return false; ++#endif ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: + + +Your approach works ok Gerd with a migration blocker. Are you going to send a patch? + +I am afraid we would have to make this code permanent though, since there has been several releases of this driver already, and it's much nicer to block migration than to crash a VM. + +I have reached out to wddm driver about the bug. + +Cc: <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/display/qxl.h | 1 + + hw/display/qxl.c | 22 ++++++++++++++++++++++ + 2 files changed, 23 insertions(+) + +diff --git a/hw/display/qxl.h b/hw/display/qxl.h +index d2d49dd..77e5a36 100644 +--- a/hw/display/qxl.h ++++ b/hw/display/qxl.h +@@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { + uint32_t cmdlog; + + uint32_t guest_bug; ++ Error *migration_blocker; + + enum qxl_mode mode; + uint32_t cmdflags; +diff --git a/hw/display/qxl.c b/hw/display/qxl.c +index c31b293..74ebeb9 100644 +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -26,6 +26,7 @@ + #include "qemu/queue.h" + #include "qemu/atomic.h" + #include "sysemu/sysemu.h" ++#include "migration/migration.h" + #include "trace.h" + + #include "qxl.h" +@@ -639,6 +640,27 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ /* ++ * Windows 8 drivers place qxl commands in the vram ++ * (instead of the ram) bar. We can't live migrate such a ++ * guest, so add a migration blocker in case we detect ++ * this, to avoid triggering the assert in pre_save(). ++ * ++ * https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa ++ */ ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg != NULL && ( ++ msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size))) { ++ if (!qxl->migration_blocker) { ++ Error *local_err = NULL; ++ error_setg(&qxl->migration_blocker, ++ "qxl: guest bug: command not in ram bar"); ++ migrate_add_blocker(qxl->migration_blocker, &local_err); ++ } ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: +-- +2.9.3 + + + +Hi + +On Mon, Apr 10, 2017 at 8:58 AM Gerd Hoffmann <email address hidden> wrote: + +> Cc: <email address hidden> +> Signed-off-by: Gerd Hoffmann <email address hidden> +> --- +> hw/display/qxl.h | 1 + +> hw/display/qxl.c | 22 ++++++++++++++++++++++ +> 2 files changed, 23 insertions(+) +> +> diff --git a/hw/display/qxl.h b/hw/display/qxl.h +> index d2d49dd..77e5a36 100644 +> --- a/hw/display/qxl.h +> +++ b/hw/display/qxl.h +> @@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { +> uint32_t cmdlog; +> +> uint32_t guest_bug; +> + Error *migration_blocker; +> +> enum qxl_mode mode; +> uint32_t cmdflags; +> diff --git a/hw/display/qxl.c b/hw/display/qxl.c +> index c31b293..74ebeb9 100644 +> --- a/hw/display/qxl.c +> +++ b/hw/display/qxl.c +> @@ -26,6 +26,7 @@ +> #include "qemu/queue.h" +> #include "qemu/atomic.h" +> #include "sysemu/sysemu.h" +> +#include "migration/migration.h" +> #include "trace.h" +> +> #include "qxl.h" +> @@ -639,6 +640,27 @@ static int interface_get_command(QXLInstance *sin, +> struct QXLCommandExt *ext) +> qxl->guest_primary.commands++; +> qxl_track_command(qxl, ext); +> qxl_log_command(qxl, "cmd", ext); +> + { +> + /* +> + * Windows 8 drivers place qxl commands in the vram +> ++ * (instead of the ram) bar. We can't live migrate such a +> + * guest, so add a migration blocker in case we detect +> + * this, to avoid triggering the assert in pre_save(). +> + * +> + * +> https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa +> + */ +> + void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); +> + if (msg != NULL && ( +> + msg < (void *)qxl->vga.vram_ptr || +> + msg > ((void *)qxl->vga.vram_ptr + +> qxl->vga.vram_size))) { +> + if (!qxl->migration_blocker) { +> + Error *local_err = NULL; +> + error_setg(&qxl->migration_blocker, +> + "qxl: guest bug: command not in ram bar"); +> + migrate_add_blocker(qxl->migration_blocker, +> &local_err); +> + } +> + +Should the blocker be removed on reset? + +Looks and works ok otherwise + + +> + } +> + } +> trace_qxl_ring_command_get(qxl->id, +> qxl_mode_to_string(qxl->mode)); +> return true; +> default: +> -- +> 2.9.3 +> +> -- +Marc-André Lureau + + +Cc: <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/display/qxl.h | 1 + + hw/display/qxl.c | 28 ++++++++++++++++++++++++++++ + 2 files changed, 29 insertions(+) + +diff --git a/hw/display/qxl.h b/hw/display/qxl.h +index d2d49dd..77e5a36 100644 +--- a/hw/display/qxl.h ++++ b/hw/display/qxl.h +@@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { + uint32_t cmdlog; + + uint32_t guest_bug; ++ Error *migration_blocker; + + enum qxl_mode mode; + uint32_t cmdflags; +diff --git a/hw/display/qxl.c b/hw/display/qxl.c +index c31b293..c1f830c 100644 +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -26,6 +26,7 @@ + #include "qemu/queue.h" + #include "qemu/atomic.h" + #include "sysemu/sysemu.h" ++#include "migration/migration.h" + #include "trace.h" + + #include "qxl.h" +@@ -639,6 +640,27 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ /* ++ * Windows 8 drivers place qxl commands in the vram ++ * (instead of the ram) bar. We can't live migrate such a ++ * guest, so add a migration blocker in case we detect ++ * this, to avoid triggering the assert in pre_save(). ++ * ++ * https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa ++ */ ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg != NULL && ( ++ msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size))) { ++ if (!qxl->migration_blocker) { ++ Error *local_err = NULL; ++ error_setg(&qxl->migration_blocker, ++ "qxl: guest bug: command not in ram bar"); ++ migrate_add_blocker(qxl->migration_blocker, &local_err); ++ } ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: +@@ -1236,6 +1258,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int loadvm) + qemu_spice_create_host_memslot(&d->ssd); + qxl_soft_reset(d); + ++ if (d->migration_blocker) { ++ migrate_del_blocker(d->migration_blocker); ++ error_free(d->migration_blocker); ++ d->migration_blocker = NULL; ++ } ++ + if (startstop) { + qemu_spice_display_start(); + } +-- +2.9.3 + + + +Hi + +On Mon, Apr 10, 2017 at 12:27 PM Gerd Hoffmann <email address hidden> wrote: + +> Cc: <email address hidden> +> Signed-off-by: Gerd Hoffmann <email address hidden> +> +--- +> hw/display/qxl.h | 1 + +> hw/display/qxl.c | 28 ++++++++++++++++++++++++++++ +> 2 files changed, 29 insertions(+) +> +> diff --git a/hw/display/qxl.h b/hw/display/qxl.h +> index d2d49dd..77e5a36 100644 +> --- a/hw/display/qxl.h +> +++ b/hw/display/qxl.h +> @@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { +> uint32_t cmdlog; +> +> uint32_t guest_bug; +> + Error *migration_blocker; +> +> enum qxl_mode mode; +> uint32_t cmdflags; +> diff --git a/hw/display/qxl.c b/hw/display/qxl.c +> index c31b293..c1f830c 100644 +> --- a/hw/display/qxl.c +> +++ b/hw/display/qxl.c +> @@ -26,6 +26,7 @@ +> #include "qemu/queue.h" +> #include "qemu/atomic.h" +> #include "sysemu/sysemu.h" +> +#include "migration/migration.h" +> #include "trace.h" +> +> #include "qxl.h" +> @@ -639,6 +640,27 @@ static int interface_get_command(QXLInstance *sin, +> struct QXLCommandExt *ext) +> qxl->guest_primary.commands++; +> qxl_track_command(qxl, ext); +> qxl_log_command(qxl, "cmd", ext); +> + { +> + /* +> + * Windows 8 drivers place qxl commands in the vram +> + * (instead of the ram) bar. We can't live migrate such a +> + * guest, so add a migration blocker in case we detect +> + * this, to avoid triggering the assert in pre_save(). +> + * +> + * +> https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa +> + */ +> + void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); +> + if (msg != NULL && ( +> + msg < (void *)qxl->vga.vram_ptr || +> + msg > ((void *)qxl->vga.vram_ptr + +> qxl->vga.vram_size))) { +> + if (!qxl->migration_blocker) { +> + Error *local_err = NULL; +> + error_setg(&qxl->migration_blocker, +> + "qxl: guest bug: command not in ram bar"); +> + migrate_add_blocker(qxl->migration_blocker, +> &local_err); +> + +What do you do with the local_err? error_report_err() perhaps ? + + +> + } +> + } +> + } +> trace_qxl_ring_command_get(qxl->id, +> qxl_mode_to_string(qxl->mode)); +> return true; +> default: +> @@ -1236,6 +1258,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int +> loadvm) +> qemu_spice_create_host_memslot(&d->ssd); +> qxl_soft_reset(d); +> +> + if (d->migration_blocker) { +> + migrate_del_blocker(d->migration_blocker); +> + error_free(d->migration_blocker); +> + d->migration_blocker = NULL; +> + } +> + +> if (startstop) { +> qemu_spice_display_start(); +> } +> -- +> 2.9.3 +> +> -- +Marc-André Lureau + + + Hi, + +> > + if (!qxl->migration_blocker) { +> > + Error *local_err = NULL; +> > + error_setg(&qxl->migration_blocker, +> > + "qxl: guest bug: command not in ram bar"); +> > + migrate_add_blocker(qxl->migration_blocker, +> > &local_err); +> > +> +> What do you do with the local_err? error_report_err() perhaps ? + +We can't error out at that point, unlike most migration blockers this +isn't added at device initialization time. + +So, yes, we could error_report it, but the message would end up in the +logfile unnoticed, so I'm not sure how useful that is ... + +cheers, + Gerd + + + +Hi + +On Mon, Apr 10, 2017 at 12:51 PM Gerd Hoffmann <email address hidden> wrote: + +> Hi, +> +> > > + if (!qxl->migration_blocker) { +> > > + Error *local_err = NULL; +> > > + error_setg(&qxl->migration_blocker, +> > > + "qxl: guest bug: command not in ram +> bar"); +> > > + migrate_add_blocker(qxl->migration_blocker, +> > > &local_err); +> > > +> > +> > What do you do with the local_err? error_report_err() perhaps ? +> +> We can't error out at that point, unlike most migration blockers this +> isn't added at device initialization time. +> +> So, yes, we could error_report it, but the message would end up in the +> logfile unnoticed, so I'm not sure how useful that is ... +> + +Well, it may eventually be read if something breaks. Otherwise, you may +just pass a NULL pointer, no? + +thanks +-- +Marc-André Lureau + + +Cc: <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/display/qxl.h | 1 + + hw/display/qxl.c | 31 +++++++++++++++++++++++++++++++ + 2 files changed, 32 insertions(+) + +diff --git a/hw/display/qxl.h b/hw/display/qxl.h +index d2d49dd..77e5a36 100644 +--- a/hw/display/qxl.h ++++ b/hw/display/qxl.h +@@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { + uint32_t cmdlog; + + uint32_t guest_bug; ++ Error *migration_blocker; + + enum qxl_mode mode; + uint32_t cmdflags; +diff --git a/hw/display/qxl.c b/hw/display/qxl.c +index c31b293..9feae78 100644 +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -26,6 +26,7 @@ + #include "qemu/queue.h" + #include "qemu/atomic.h" + #include "sysemu/sysemu.h" ++#include "migration/migration.h" + #include "trace.h" + + #include "qxl.h" +@@ -639,6 +640,30 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ /* ++ * Windows 8 drivers place qxl commands in the vram ++ * (instead of the ram) bar. We can't live migrate such a ++ * guest, so add a migration blocker in case we detect ++ * this, to avoid triggering the assert in pre_save(). ++ * ++ * https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa ++ */ ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg != NULL && ( ++ msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size))) { ++ if (!qxl->migration_blocker) { ++ Error *local_err = NULL; ++ error_setg(&qxl->migration_blocker, ++ "qxl: guest bug: command not in ram bar"); ++ migrate_add_blocker(qxl->migration_blocker, &local_err); ++ if (local_err) { ++ error_report_err(local_err); ++ } ++ } ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: +@@ -1236,6 +1261,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int loadvm) + qemu_spice_create_host_memslot(&d->ssd); + qxl_soft_reset(d); + ++ if (d->migration_blocker) { ++ migrate_del_blocker(d->migration_blocker); ++ error_free(d->migration_blocker); ++ d->migration_blocker = NULL; ++ } ++ + if (startstop) { + qemu_spice_display_start(); + } +-- +2.9.3 + + + +Is this problem limited to commands or also to data attached to the commands? +To me looks like a limitation Qemu should remove on the long run. + +Hi + +On Mon, Apr 10, 2017 at 1:31 PM Gerd Hoffmann <email address hidden> wrote: + +> Cc: <email address hidden> +> Signed-off-by: Gerd Hoffmann <email address hidden> +> + + +Reviewed-by: Marc-André Lureau <email address hidden> + + + +> --- +> hw/display/qxl.h | 1 + +> hw/display/qxl.c | 31 +++++++++++++++++++++++++++++++ +> 2 files changed, 32 insertions(+) +> +> diff --git a/hw/display/qxl.h b/hw/display/qxl.h +> index d2d49dd..77e5a36 100644 +> --- a/hw/display/qxl.h +> +++ b/hw/display/qxl.h +> @@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { +> uint32_t cmdlog; +> +> uint32_t guest_bug; +> + Error *migration_blocker; +> +> enum qxl_mode mode; +> uint32_t cmdflags; +> diff --git a/hw/display/qxl.c b/hw/display/qxl.c +> index c31b293..9feae78 100644 +> --- a/hw/display/qxl.c +> +++ b/hw/display/qxl.c +> @@ -26,6 +26,7 @@ +> #include "qemu/queue.h" +> #include "qemu/atomic.h" +> #include "sysemu/sysemu.h" +> +#include "migration/migration.h" +> #include "trace.h" +> +> #include "qxl.h" +> @@ -639,6 +640,30 @@ static int interface_get_command(QXLInstance *sin, +> struct QXLCommandExt *ext) +> qxl->guest_primary.commands++; +> qxl_track_command(qxl, ext); +> qxl_log_command(qxl, "cmd", ext); +> + { +> + /* +> + * Windows 8 drivers place qxl commands in the vram +> + * (instead of the ram) bar. We can't live migrate such a +> + * guest, so add a migration blocker in case we detect +> + * this, to avoid triggering the assert in pre_save(). +> + * +> + * +> https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa +> + */ +> + void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); +> + if (msg != NULL && ( +> + msg < (void *)qxl->vga.vram_ptr || +> + msg > ((void *)qxl->vga.vram_ptr + +> qxl->vga.vram_size))) { +> + if (!qxl->migration_blocker) { +> + Error *local_err = NULL; +> + error_setg(&qxl->migration_blocker, +> + "qxl: guest bug: command not in ram bar"); +> + migrate_add_blocker(qxl->migration_blocker, +> &local_err); +> + if (local_err) { +> + error_report_err(local_err); +> + } +> + } +> + } +> + } +> trace_qxl_ring_command_get(qxl->id, +> qxl_mode_to_string(qxl->mode)); +> return true; +> default: +> @@ -1236,6 +1261,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int +> loadvm) +> qemu_spice_create_host_memslot(&d->ssd); +> qxl_soft_reset(d); +> +> + if (d->migration_blocker) { +> + migrate_del_blocker(d->migration_blocker); +> + error_free(d->migration_blocker); +> + d->migration_blocker = NULL; +> + } +> + +> if (startstop) { +> qemu_spice_display_start(); +> } +> -- +> 2.9.3 +> +> -- +Marc-André Lureau + + +On Mo, 2017-04-10 at 11:56 +0000, Frediano Ziglio wrote: +> Is this problem limited to commands or also to data attached to the commands? + +Everything which contains QXLReleaseInfo and is released via release +ring. + +> To me looks like a limitation Qemu should remove on the long run. + +That is an option, but it is tricky backward-compatibility wise. +What was the reason to move the commands to bar1? + +cheers, + Gerd + + + +Cc: <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +Message-id: <email address hidden> +--- + hw/display/qxl.h | 1 + + hw/display/qxl.c | 31 +++++++++++++++++++++++++++++++ + 2 files changed, 32 insertions(+) + +diff --git a/hw/display/qxl.h b/hw/display/qxl.h +index d2d49dd..77e5a36 100644 +--- a/hw/display/qxl.h ++++ b/hw/display/qxl.h +@@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { + uint32_t cmdlog; + + uint32_t guest_bug; ++ Error *migration_blocker; + + enum qxl_mode mode; + uint32_t cmdflags; +diff --git a/hw/display/qxl.c b/hw/display/qxl.c +index c31b293..9feae78 100644 +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -26,6 +26,7 @@ + #include "qemu/queue.h" + #include "qemu/atomic.h" + #include "sysemu/sysemu.h" ++#include "migration/migration.h" + #include "trace.h" + + #include "qxl.h" +@@ -639,6 +640,30 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ /* ++ * Windows 8 drivers place qxl commands in the vram ++ * (instead of the ram) bar. We can't live migrate such a ++ * guest, so add a migration blocker in case we detect ++ * this, to avoid triggering the assert in pre_save(). ++ * ++ * https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa ++ */ ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg != NULL && ( ++ msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size))) { ++ if (!qxl->migration_blocker) { ++ Error *local_err = NULL; ++ error_setg(&qxl->migration_blocker, ++ "qxl: guest bug: command not in ram bar"); ++ migrate_add_blocker(qxl->migration_blocker, &local_err); ++ if (local_err) { ++ error_report_err(local_err); ++ } ++ } ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: +@@ -1236,6 +1261,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int loadvm) + qemu_spice_create_host_memslot(&d->ssd); + qxl_soft_reset(d); + ++ if (d->migration_blocker) { ++ migrate_del_blocker(d->migration_blocker); ++ error_free(d->migration_blocker); ++ d->migration_blocker = NULL; ++ } ++ + if (startstop) { + qemu_spice_display_start(); + } +-- +2.9.3 + + + +Did I miss something or this is a bug in the windows qxl driver and should be fixed there? + +Will be fixed in the windows driver, yes. + +But throwing core dumps isn't exactly nice, even in case the guest is buggy, thats why the qemu workaround, so we simply refuse to live-migrate instead of crashing. + +Next version of the driver will solve the problem (already fixed in master). + +Similar issue, seems not caused by save/restore/migration but is still detecting offset problems with resource deallocation. +See https://lists.freedesktop.org/archives/spice-devel/2017-April/037248.html. + +Still working on some updates for the driver. + +wddm dod 0.17 version released which fixes the issue guest side. + +Patch had been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=86dbcdd9c7590d06db89ca +... thus closing this ticket now. + diff --git a/results/classifier/zero-shot/108/none/1650175 b/results/classifier/zero-shot/108/none/1650175 new file mode 100644 index 000000000..f09a09a61 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1650175 @@ -0,0 +1,35 @@ +semantic: 0.466 +network: 0.438 +device: 0.354 +graphic: 0.316 +socket: 0.301 +other: 0.271 +vnc: 0.240 +files: 0.232 +PID: 0.116 +permissions: 0.109 +boot: 0.102 +KVM: 0.087 +debug: 0.064 +performance: 0.064 + +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/zero-shot/108/none/1655702 b/results/classifier/zero-shot/108/none/1655702 new file mode 100644 index 000000000..d0d28f504 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1655702 @@ -0,0 +1,32 @@ +graphic: 0.585 +device: 0.440 +performance: 0.437 +other: 0.364 +network: 0.355 +semantic: 0.323 +vnc: 0.305 +socket: 0.246 +PID: 0.140 +KVM: 0.139 +debug: 0.124 +boot: 0.087 +files: 0.086 +permissions: 0.041 + +qemu/hw/char/exynos4210_uart.c: possible pointless local variable ? + +$ fgrep frame_size qemu/hw/char/exynos4210_uart.c + int speed, parity, data_bits, stop_bits, frame_size; + frame_size = 1; /* start bit */ + frame_size++; /* parity bit */ + frame_size += data_bits + stop_bits; +$ + +Suggest either use it or delete it. + +Thanks for the report -- patch sent to mailing list which deletes the variable. + + +Now fixed in git master, commit e62694a078f182. + + diff --git a/results/classifier/zero-shot/108/none/1660 b/results/classifier/zero-shot/108/none/1660 new file mode 100644 index 000000000..90830d8ef --- /dev/null +++ b/results/classifier/zero-shot/108/none/1660 @@ -0,0 +1,16 @@ +device: 0.424 +semantic: 0.364 +graphic: 0.281 +network: 0.195 +files: 0.190 +vnc: 0.104 +other: 0.095 +performance: 0.091 +boot: 0.083 +debug: 0.055 +PID: 0.054 +permissions: 0.029 +socket: 0.019 +KVM: 0.011 + +tests/avocado/linux_ssh_mips_malta.py references mips image URLs that doesn't exist any more diff --git a/results/classifier/zero-shot/108/none/1660010 b/results/classifier/zero-shot/108/none/1660010 new file mode 100644 index 000000000..cfdfc0be1 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1660010 @@ -0,0 +1,58 @@ +semantic: 0.558 +files: 0.551 +device: 0.542 +PID: 0.541 +socket: 0.517 +network: 0.473 +performance: 0.443 +graphic: 0.418 +vnc: 0.394 +other: 0.364 +permissions: 0.328 +boot: 0.264 +debug: 0.208 +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/zero-shot/108/none/1668556 b/results/classifier/zero-shot/108/none/1668556 new file mode 100644 index 000000000..7a5f5bca8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1668556 @@ -0,0 +1,39 @@ +graphic: 0.344 +socket: 0.334 +semantic: 0.327 +device: 0.303 +other: 0.293 +vnc: 0.156 +KVM: 0.154 +permissions: 0.113 +PID: 0.108 +boot: 0.093 +files: 0.083 +network: 0.081 +performance: 0.073 +debug: 0.047 + +QEMU Guest Agent service fails to start on Windows 10 RS2 preview + +The "QEMU Guest Agent" service cannot be started on Windows 10 RS2 preview build. After starting the service this error message is displayed: "Windows could not start QEMU Guest Agent service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." + +Output from the Windows System event log: +<?xml version="1.0" encoding="utf-8" standalone="yes"?> +<Events><Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Service Control Manager' Guid='{555908d1-a6d7-4695-8e1e-26931d2012f4}' EventSourceName='Service Control Manager'/><EventID Qualifiers='49152'>7009</EventID><Version>0</Version><Level>2</Level><Task>0</Task><Opcode>0</Opcode><Keywords>0x8080000000000000</Keywords><TimeCreated SystemTime='2017-02-28T09:39:35.713939500Z'/><EventRecordID>1406</EventRecordID><Correlation/><Execution ProcessID='568' ThreadID='964'/><Channel>System</Channel><Computer>LT-WIN10-64</Computer><Security/></System><EventData><Data Name='param1'>30000</Data><Data Name='param2'>QEMU Guest Agent</Data><Binary>510045004D0055002D00470041000000</Binary></EventData></Event></Events> + +The "QEMU Guest Agent VSS Provider" service is running successfully. + +It worked on Windows 10 RS1 (before the upgrade). + +QEMU Guest Agent version: +Installed from virtio-win-0.1.126_amd64 +which was built from master branch with latest commit (8aaf403) - https://github.com/virtio-win/kvm-guest-drivers-windows + +Windows version (upgraded from RS1): +Windows 10 Enterprise Insider Preview +Evaluation copy. Build 15019.rs_prerelease.170121-1513 + +Not a bug! + +I have forgotten to add the socket in the start script :( + diff --git a/results/classifier/zero-shot/108/none/1671876 b/results/classifier/zero-shot/108/none/1671876 new file mode 100644 index 000000000..bdbe3812c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1671876 @@ -0,0 +1,197 @@ +KVM: 0.566 +vnc: 0.523 +performance: 0.519 +other: 0.474 +device: 0.468 +graphic: 0.446 +debug: 0.434 +network: 0.418 +socket: 0.397 +semantic: 0.379 +permissions: 0.378 +PID: 0.377 +files: 0.360 +boot: 0.341 + +qemu 2.7.0 segfaults in qemu_co_queue_run_restart() + +I've been experiencing frequent segfaults lately with qemu 2.7.0 running Ubuntu 16.04 guests. The crash usually happens in qemu_co_queue_run_restart(). I haven't seen this so far with any other guests or distros. + +Here is one back trace I obtained from one of the crashing VMs. + +------------------------------------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7fba8ff05aa0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8ff05aa0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd20430) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#3 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd20430) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#4 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd14ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#5 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd14ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#6 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba80c11dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#7 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba80c11dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#8 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd0bd70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#9 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd0bd70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#10 0x000055c1656f3fa0 in qemu_co_enter_next (queue=queue@entry=0x55c1669e75e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#11 0x000055c165692060 in timer_cb (blk=0x55c1669e7590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#12 0x000055c16564f615 in timerlist_run_timers (timer_list=0x55c166a53e80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#13 0x000055c16564f679 in timerlistgroup_run_timers (tlg=tlg@entry=0x55c167c81cf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#14 0x000055c16564ff47 in aio_dispatch (ctx=ctx@entry=0x55c167c81bb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#15 0x000055c1656500e8 in aio_poll (ctx=0x55c167c81bb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#16 0x000055c1654b1c79 in iothread_run (opaque=0x55c167c81960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#17 0x00007fbc4b64f0a4 in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0x0) at allocatestack.c:416 +#18 __pthread_create_2_1 (newthread=<error reading variable: Cannot access memory at address 0xffffffffffffff48>, attr=<error reading variable: Cannot access memory at address 0xffffffffffffff40>, + start_routine=<error reading variable: Cannot access memory at address 0xffffffffffffff58>, arg=<error reading variable: Cannot access memory at address 0xffffffffffffff50>) at pthread_create.c:539 +Backtrace stopped: Cannot access memory at address 0x8 +------------------------------------------------------------------------------------------------- + +The code that crashes is this +------------------------------------------------------------------------------------------------- +void qemu_co_queue_run_restart(Coroutine *co) +{ + Coroutine *next; + + trace_qemu_co_queue_run_restart(co); + while ((next = QSIMPLEQ_FIRST(&co->co_queue_wakeup))) { + QSIMPLEQ_REMOVE_HEAD(&co->co_queue_wakeup, co_queue_next); <--- Crash occurs here this time + qemu_coroutine_enter(next); + } +} +------------------------------------------------------------------------------------------------- + +Expanding the macro QSIMPLEQ_REMOVE_HEAD gives us +------------------------------------------------------------------------------------------------- +#define QSIMPLEQ_REMOVE_HEAD(head, field) do { \ + if (((head)->sqh_first = (head)->sqh_first->field.sqe_next) == NULL)\ + (head)->sqh_last = &(head)->sqh_first; \ +} while (/*CONSTCOND*/0) +------------------------------------------------------------------------------------------------- + +which corrsponds to +------------------------------------------------------------------------------------------------- +if (((&co->co_queue_wakeup)->sqh_first = (&co->co_queue_wakeup)->sqh_first->co_queue_next.sqe_next) == NULL)\ + (&co->co_queue_wakeup)->sqh_last = &(&co->co_queue_wakeup)->sqh_first; +------------------------------------------------------------------------------------------------- + +Debugging the list we see +------------------------------------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$6 = (struct Coroutine *) 0x1000 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0x1030 +------------------------------------------------------------------------------------------------- + +So the data in co->co_queue_wakeup->sqh_first is corrupted and represents an invalid address. Any idea why is that? + +Another stack trace + +--------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7f668be15260) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x0000564cb19f59a9 in qemu_coroutine_enter (co=0x7f668be15260) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x0000564cb19f5fa0 in qemu_co_enter_next (queue=queue@entry=0x564cb35e55e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#3 0x0000564cb1994060 in timer_cb (blk=0x564cb35e5590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#4 0x0000564cb1951615 in timerlist_run_timers (timer_list=0x564cb3651e80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#5 0x0000564cb1951679 in timerlistgroup_run_timers (tlg=tlg@entry=0x564cb487fcf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#6 0x0000564cb1951f47 in aio_dispatch (ctx=ctx@entry=0x564cb487fbb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#7 0x0000564cb19520e8 in aio_poll (ctx=0x564cb487fbb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#8 0x0000564cb17b3c79 in iothread_run (opaque=0x564cb487f960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#9 0x00007f684b0b30a4 in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0x0) at allocatestack.c:416 +#10 __pthread_create_2_1 (newthread=<error reading variable: Cannot access memory at address 0xffffffffffffff48>, attr=<error reading variable: Cannot access memory at address 0xffffffffffffff40>, + start_routine=<error reading variable: Cannot access memory at address 0xffffffffffffff58>, arg=<error reading variable: Cannot access memory at address 0xffffffffffffff50>) at pthread_create.c:539 +Backtrace stopped: Cannot access memory at address 0x8 +----------------------------------------------------------------------------------------------- + + +Here is a bit of examination of the data +----------------------------------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$1 = (struct Coroutine *) 0xc54b578 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0xc54b5a8 +----------------------------------------------------------------------------------------------- + +Again seems to be pointing at an invalid address. It's worth noting here that it the number of restarted and re-run co-routines is much smaller. + +A third stack trace + +It generates the following stack trace +--------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7f75ed30dbc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed30dbc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75f1c0f200) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#3 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75f1c0f200) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#4 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed304870) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#5 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed304870) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#6 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800fcd0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#7 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800fcd0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#8 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800fac0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#9 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800fac0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#10 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800f8b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#11 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800f8b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#12 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75fbf05570) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#13 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75fbf05570) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#14 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8009b70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#15 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8009b70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#16 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800b5d0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#17 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800b5d0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#18 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8008910) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#19 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8008910) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#20 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800f6a0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#21 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800f6a0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#22 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75fbf05100) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#23 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75fbf05100) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#24 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75fbf04ee0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#25 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75fbf04ee0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#26 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed301c50) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#27 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed301c50) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#28 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed315270) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#29 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed315270) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#30 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed31cf10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#31 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed31cf10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#32 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800a970) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#33 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800a970) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#34 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8007df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#35 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8007df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#36 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8005960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#37 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8005960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#38 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800e1b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#39 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800e1b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#40 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8000a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#41 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8000a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#42 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8007900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#43 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8007900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#44 0x0000561927482fa0 in qemu_co_enter_next (queue=queue@entry=0x5619288d15e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#45 0x0000561927421060 in timer_cb (blk=0x5619288d1590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#46 0x00005619273de615 in timerlist_run_timers (timer_list=0x56192893de80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#47 0x00005619273de679 in timerlistgroup_run_timers (tlg=tlg@entry=0x561929b6bcf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#48 0x00005619273def47 in aio_dispatch (ctx=ctx@entry=0x561929b6bbb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#49 0x00005619273df0e8 in aio_poll (ctx=0x561929b6bbb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#50 0x0000561927240c79 in iothread_run (opaque=0x561929b6b960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#51 0x00007f77b32160a4 in start_thread (arg=0x7f77997ff700) at pthread_create.c:403 +#52 0x00007f77b2f4b62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +--------------------------------------------------------------------- + +It's also crashing in list traversal. Looking at the contained data we see: + +--------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$1 = (struct Coroutine *) 0x1 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0x31 +--------------------------------------------------------------------- + +So again. Segfault is caused by apparently invalid addresses. And this time it occurs after so many invocations of qemu_co_queue_run_restart() + +The VMs were running with the following arguments +--------------------------------------------------------------------- +-m 1024,slots=255,maxmem=256G -M pc-i440fx-2.7 -enable-kvm -nodefconfig -nodefaults -rtc base=utc -netdev tap,ifname=n020133f0895e,id=hostnet6,vhost=on,vhostforce=on,vnet_hdr=off,script=no,downscript=no -device virtio-net-pci,netdev=hostnet6,id=net6,mac=02:01:33:f0:89:5e,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:94 -vga qxl -cpu Haswell,+vmx -smp 6,sockets=32,cores=1,maxcpus=64,threads=2 -drive file=/dev/md10,if=none,id=drive-virtio-disk5,format=raw,snapshot=off,aio=native,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk5,num-queues=3,id=virtio-disk5,bootindex=1 -S +--------------------------------------------------------------------- + + +Could you please retry with the latest stable version (either 2.8.0 or 2.7.1) ... maybe the problem is already fixed there. + +Unfortunately it'd not be possible to use another version at the moment. Is it possible that someone takes a look at the stack traces? + +Fixed by commit 528f449f590829b53ea01ed91817a695b540421d + diff --git a/results/classifier/zero-shot/108/none/1673976 b/results/classifier/zero-shot/108/none/1673976 new file mode 100644 index 000000000..ac4197097 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1673976 @@ -0,0 +1,321 @@ +other: 0.587 +graphic: 0.580 +device: 0.532 +semantic: 0.510 +permissions: 0.489 +vnc: 0.481 +debug: 0.457 +performance: 0.456 +PID: 0.450 +socket: 0.443 +network: 0.410 +KVM: 0.399 +boot: 0.383 +files: 0.324 + +linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) + +I'm running a command command (locale-gen) inside of an armv7h chroot mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the chroot file system and I get a core dump. + +locale-gen +Generating locales... + en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +/usr/bin/locale-gen: line 41: 34 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale + +I've done this same thing successfully for years, but this breakage has appeared some time in the last 3 or so months. Possibly with the update to qemu version 2.8. + +I can confirm this. The ninja build system is also affected. + +Could you please check whether the problem also occurs with QEMU v2.10? + +Hi, + +I can confirm it with QEMU 2.10.0 (running Gentoo Linux) + +Portage 2.3.10 (python 2.7.14-final-0, default/linux/amd64/17.0/no-multilib, gcc-7.2.0, glibc-2.25-r5, 4.13.4-gentoo x86_64) + + +# uname -a && locale-gen +Linux **** 4.13.4-gentoo #1 SMP PREEMPT Thu Sep 28 09:41:30 CEST 2017 armv7l Intel(R) Celeron(R) 2957U @ 1.40GHz GNU/Linux + * Generating 8 locales (this might take a while) with 2 jobs + * (2/8) Generating en_US.UTF-8 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (1/8) Generating en_US.ISO-8859-1 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (3/8) Generating fr_BE.ISO-8859-15@euro ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (4/8) Generating fr_BE.ISO-8859-1 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (5/8) Generating fr_BE.UTF-8 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (6/8) Generating fr_FR.ISO-8859-15@euro ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (7/8) Generating fr_FR.ISO-8859-1 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (8/8) Generating fr_FR.UTF-8 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * Generation complete + * Adding locales to archive ... +incomplete set of locale files in "//usr/lib/locale/en_US" +incomplete set of locale files in "//usr/lib/locale/en_US.utf8" +incomplete set of locale files in "//usr/lib/locale/fr_BE" +incomplete set of locale files in "//usr/lib/locale/fr_BE@euro" +incomplete set of locale files in "//usr/lib/locale/fr_BE.utf8" +incomplete set of locale files in "//usr/lib/locale/fr_FR" +incomplete set of locale files in "//usr/lib/locale/fr_FR@euro" +incomplete set of locale files in "//usr/lib/locale/fr_FR.utf8" [ !! ] + + +Looks like the __clone() call is failing for some reason: + +https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/spawni.c;h=dea1650d08ded5fd848f263aebebe8748e703697;hb=HEAD#l362 + + + +Here is a workaround: + +cd /usr/share/i18n/charmaps +gunzip --keep UTF-8.gz +locale-gen en_US.UTF-8 + + + +It is possible to reproduce the issue with a simple clone example taken from + + http://man7.org/linux/man-pages/man2/clone.2.html + + +# qemu-aarch64-static -strace ./a.out testname +585 brk(NULL) = 0x0000004000013000 +585 uname(0x4000812d08) = 0 +585 faccessat(AT_FDCWD,"/etc/ld.so.nohwcap",F_OK,0x82e888) = -1 errno=2 (No such file or directory) +585 mmap(NULL,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000004000843000 +585 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,AT_SYMLINK_NOFOLLOW|0x82d848) = -1 errno=2 (No such file or directory) +585 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3 +585 fstat(3,0x0000004000812680) = 0 +585 mmap(NULL,20645,PROT_READ,MAP_PRIVATE,3,0) = 0x0000004000846000 +585 close(3) = 0 +585 faccessat(AT_FDCWD,"/etc/ld.so.nohwcap",F_OK,0x82e888) = -1 errno=2 (No such file or directory) +585 openat(AT_FDCWD,"/lib/aarch64-linux-gnu/libc.so.6",O_RDONLY|O_CLOEXEC) = 3 +585 read(3,0x812830,832) = 832 +585 fstat(3,0x00000040008126d0) = 0 +585 mmap(NULL,1393456,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x000000400084c000 +585 mprotect(0x0000004000987000,65536,PROT_NONE) = 0 +585 mmap(0x0000004000997000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x13b000) = 0x0000004000997000 +585 mmap(0x000000400099d000,13104,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x000000400099d000 +585 close(3) = 0 +585 mprotect(0x0000004000997000,16384,PROT_READ) = 0 +585 mprotect(0x0000004000011000,4096,PROT_READ) = 0 +585 mprotect(0x0000004000840000,4096,PROT_READ) = 0 +585 munmap(0x0000004000846000,20645) = 0 +585 brk(NULL) = 0x0000004000013000 +585 brk(0x0000004000034000) = 0x0000004000013000 +585 mmap(NULL,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000040009a1000 +585 mmap(NULL,1052672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000004000aa1000 +585 clone(CLONE_NEWUTS|0x11,child_stack=0x0000004000ba1010,parent_tidptr=0x0000004000aa1010,tls=0x0000000000000000,child_tidptr=0x0000000000000000) = -1 errno=22 (Invalid argument) +585 dup(2,4222427270,274886578000,22,0,0) = 3 +585 fcntl(3,F_GETFL) = 1026 +585 fstat(3,0x0000004000812628) = 0 +585 write(3,0x9a1490,24)clone: Invalid argument + = 24 +585 close(3) = 0 +585 exit_group(1) + + +# strace ./a.out testname +qemu: Unsupported syscall: 117 +qemu: Unsupported syscall: 117 +/usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented ++++ exited with 1 +++ + + +This happens because QEMU is now stricter about its checking of the flags passed to clone() -- previously we would silently allow flags we couldn't support and create new threads with the wrong behaviour. Now we check and fail the clone() syscall if the requested behaviour is something we can't implement. Unfortunately we don't have any way to distinguish "guest program is asking for something odd that it doesn't really need" from "guest program is asking for something odd that it does need". So we err on the safe side and tell the guest we can't do it. + +It's particularly unfortunate that the glibc implementation of posix_spawn() runs into this, though. + + +Is there a way I can ask QEMU to not do this strict checking so that my stuff stops breaking? + +Not without messing with the QEMU source, no. + + +OK, this can't be as simple as "posix_spawn() fails", because I've just tried the test program from the posix_spawn manpage (http://man7.org/linux/man-pages/man3/posix_spawn.3.html) and that works fine for x86-64 guest, aarch64 guest and armhf guest. In the x86 and armhf cases the libc I have seems to use the NR_vfork syscall, but for aarch64 it uses clone(CLONE_VM | CLONE_VFORK | SIGCHLD, ...) which is what the glibc sources linked in comment #5 do, and that all works fine. + +And locale-gen runs fine for my xenial-armhf chroot using current head-of-git QEMU: + +root@e104462:/# locale-gen +Generating locales (this might take a while)... + en_GB.UTF-8... done +Generation complete. + +So can I ask that people: (1) please try with current head of git (or with 2.11-rc1, which is almost the same thing); (2) if there's still a problem with localegen or with programs calling posix_spawn() or other real-world code, please provide full repro instructions so I can try to reproduce locally. + +I don't think we can make clone() in general work, so oddball demo code like the example program in the clone(2) manpage is out of scope, but there may well be specific cases we can address. + + +I can reproduce the bug in a mips64el chroot running current Debian unstable - the posix_spawn example you mention fails there. I have tested v2.11.0-rc2 and it fails there as well. I think you need glibc >= 2.25 to trigger the bug (artful / bionic chroot). I only noticed it due to Debian updating to a newer glibc recently. + +I think I see the problem. This glibc commit rewrote the posix_spawn implementation on Linux: +https://sourceware.org/git/?p=glibc.git;a=commit;h=9ff72da471a509a8c19791efe469f47fa6977410 + +It now relies on the exact behavior of clone(CLONE_VM | CLONE_VFORK) - ie: +- That the parent will wait for the child to exec before continuing. +- Writes to memory in the child are later visible in the parent + +QEMU emulates this clone using fork() which no longer works properly and causes the assertion failure. + +Sorry, this is probably the commit that broke things (not the one above). I was added in glibc 2.25: +https://sourceware.org/git/?p=glibc.git;a=commit;h=4b4d4056bb154603f36c6f8845757c1012758158 + +Thanks for tracking down the glibc change; I will try to set up a chroot with a more recent glibc to see whether we can do something that fixes that posix_spawn implementation... + +Interestingly, this also affects Microsoft Windows Services For Linux, i.e. Microsoft's Linux emulation layer. + +> https://github.com/Microsoft/WSL/issues/1878 + +I have verified that this patch [1] in glibc_2.25 and glibc_2.26 fixes the assert. + +> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22273 + +This should probably be put under 'glibc', since this is really an issue with that package, which is fixed by the way since Oct 2017. + +https://sourceware.org/git/?p=glibc.git;a=commit;h=fe05e1cb6d64dba6172249c79526f1e9af8f2bfd + +This should also be backported to 17.10 + + +That glibc change has caused the assert to go away, but QEMU's spawn(CLONE_VFORK) still does not have the "always waits for child" semantics that glibc has assumed since glibc commit 4b4d4056bb154. The child and the parent will end up racing each other, and the child will never be able to write to the parent's address space. I think that the effect of that race will be that if the child fails (for instance if a bad filename is passed and exec() fails) the parent will never notice and will return a success code from the spawn function when it should not. + +So there remains a QEMU bug here; though it is also the case that I can't see any way we can fix it. + + +Ok, thank you for clearing that up. + +I'm noticing in 4b4d4056bb154 this comment: + +"...we just make explicit use of the fact the the child and parent run in the same VM, so the child can write an error code to a field of the posix_spawn_args struct instead of sending it through a pipe. To ensure that this mechanism really works, the parent initializes the field to -1 and the child writes 0 before execing." + +So, if the child fail to execute, that error code field of the posix_spawn_args struct will remain -1. Would this ensure that QEMU return error in case of failing exec? + +Best Regards, +Eric + +Commit fe05e1cb6d64db changed that, so args.err is initialized to zero. + + +Ok, yes you are right... + +I have looked a bit more on the source code, and indeed, I think understand the issue with the VFORK with QEMU. Please correct me if I'm wrong... + +- In the syscall trap handler, it has to use the fork() function to emulate the vfork() due to restriction of the vfork() function (as QEMU must continue to control the flow of instruction past the call to vfork(), and do a lot more things in the child thread before ending up performing a execve() or _exit()) +- Also, it can not do a wait() for the emulated child, as this child will continue to exist even after it calls execve(), so the parent would stall. +- Then, I taught about doing condition signalling, like waiting for a pthread condition signal that the child would send once it come to the point of performing the _exit() or execve(), but the child would, for example, need to know if execve() was successful, or otherwise the child would continue and set an error flag and then call _exit(). We do need that error flag before continuing the execution on the parent. So we can not signal back to the parent that the 'emulated vfork' is OK before calling execve(), but we can not wait after execve() because if the call is successful, there is no return from that function, and code goes outside the control of QEMU. + +So, I taught of an idea... What if, in the TARGET_NR_clone syscall trap, when we are called upon a CLONE_VFORK, we do: +- Do a regular fork, as it's currently done, with CLONE_VM flag (so the child share the same memory as the parent). However, we also set a state flag that we are in this 'vfork emulation' mode just before the fork (more on that bellow...). +- Let the parent wait for the child to terminate (again, more on that bellow...). +- Let the child return normally and continue execution, as if the parent was waiting. + +Then, eventually the child will eventually either end up in the TARGET_NR_execve or __NR_exit_group syscall trap. At which point: +- The child check if it is in 'vfork emulation' mode. If not, then there's nothing special, just continue the way the code is currently written. If the flag is set, then follow on with the steps bellow... +- The child set a flag that tell where it is (TARGET_NR_execve or __NR_exit_group, and the arguments passed to that syscall), and that everything is ok (it has not simply died meanwhile). +- The child terminate, which resume the parent's execution. + +The parent then: +- Clear the 'vfork emulation' flag. +- Look at where the child left (was it performing TARGET_NR_execve or __NR_exit_group syscall? What was the arguments passed to the syscall?). This is pretty easy since the child was writing to the parent's memory space the whole time (CLONE_VM). The parent could even use a flag allocated on it's stack before the fork(), since the child will have run with it's own stack during that time (so the parent stack is still intact). +- Now that we know what the child wanted to do (what syscall and which parameters), the parent (which at his point has no more 'leftover' child), can then do a *real* vfork, or otherwise return the proper error code. + +It's a bit far fetched, and I'm far from implying that I know much about QEMU, but this is an idea :-) Sound like it's pretty straightforward though. Basically we just wait for the code between the _clone() function and the _execve/_exit function to complete, at which point we take action and we are in measure to assess the status code (and do the real vfork). + +Regards, +Eric + + +Unfortunately that won't work, because if we do a clone(CLONE_VM) in QEMU that will mean that parent and child share not just the guest address space, but also all the QEMU data structures for the emulated CPUs and also the host libc data structures. Then actions done by the child will update those data structures and break execution of the parent when it resumes. + + +Ok, I taught that could be an issue, but as I said, I don't really know all the internals of QEMU. + +Another idea would be to fork the child, without CLONE_VM, on the initial call to the clone syscall, like it's done right now, and then wait for that child until he call execve or exit syscall. Maybe using some shared memory or IPC to pass the relevant status when the child finally invoke those syscalls. + +When the child finally call one of those, then after signalling the parent about where it is (and the params to the syscall), the child could exit and the parent actually take action. + +Regards, +Eric + + +That way round the child doesn't have the shared memory with the parent, so it can't update the parent's status variable. There's no easy way to say "fork, and then share the guest memory mappings and only the guest memory mappings with the child", because QEMU doesn't currently track what memory the guest has mapped at all. + + +Hello + +Sorry for the delay... + +Actually, you only need the parent to get the status from the child, which can be passed in other way than through common memory. + +The idea is to use pipefd to actually wait for the child to either terminate or successfully call execve. As follow: + + +When the TARGET_NR_clone syscall is trapped, you do: +- Call do_fork(), as currently done +- In do_fork(), at the beginning, if CLONE_VFORK flag is set, keep track of it (i.e. do not clear the flag, just clear the CLONE_VM, as currently done, to do a normal fork, i.e. the child have it's own copy of the memory segments). +- Just before the call to fork(), create a pipefd. +- The parent branch and then (if CLONE_VFORK is set) close the write end of the pipe (it's own copy), and start looping (could be indefinitely, but preferably some sort of timeout logic could be set) on the read fd, waiting continuously for status updates from the child. +- The child branch close the read-end of the pipe (it's own forked copy), set the write-end fd flag FD_CLOEXEC (with fnctl()), and put the write fd into it's QEMU state variables (parent vfork fd). +- The child then move on. + +When the TARGET_NR_execve syscall is trapped (this is in child context), you do: +- Do everything as currently done, up to just before the safe_execve() call. +- Just before the call to safe_execve(), check if the QEMU state variable (parent vfork fd) is defined. If so, tell the the parent (through the pipe), that we are good so far, and about to call execve(). Note that the parent just update the child status, but keep looping endlessly. +- Call the execve(). +- If the above call return, an error occurred. If this occur, check if the QEMU state variable (parent vfork fd) is defined. If so, tell whatever error status you got to the parent (through the pipe). The parent update it's child status, but again, continue to loop endlessly. +- Continue normally. + +That's pretty much the bulk of the work done! What will happen: +- Either the child will eventually call execve, which will succeed, at which point the write end of the pipe will be closed (because we set the pipe to close on execve, with the FD_CLOEXEC flag). +- The child could be playing on us, and try to re-call execve() multiple times (possibly with different arguments, executables path, etc.), but every time, the parent will just receive status update through the pipe. And eventually, the above case will occur (success), and pipe will be closed. +- The child call _exit(), which will close the pipe again. +- The child get some horrible signal, get killed, or whatever else... Pipe still get closed. + +The parent, on it's side, just update the status endlessly, UNTIL the other end of the pipe get closed. At this point, the read() of the pipe will get a 'broken pipe' error. This signal the parent to move on, and return whatever status the child last provided. + +Note that this status could initially be set to an error state (in case the child die or call _exit() before calling execve()). + +The only thing that could make the parent hang is if the child hang (and never call execve() or _exit() or die...). But the beauty is that this is perfectly fine, because that is exactly the required behavior when CLONE_VFORK flag is set (parent wait for the child). + + +This is a lot of description, but should be relatively easy and straightforward to implement. Could this work? + +There are a few examples similar to this on the Web, using pipefd, fork and execve, for different applications. Here, we just pass the status. + +Regards, +Eric + + +> Actually, you only need the parent to get the status from the child, which can be passed in other way than through common memory. + +Certainly, it *can* be, but the glibc code we're trying to run in the guest here doesn't do it in some other way, it uses common memory. Having QEMU effectively pause the parent process until the child has done its execve is certainly possible along the lines you suggest. But that is only half the requirement -- the parent also has to be able to see in its memory space the updates to the status variable that the child has made. + +If you're willing to change the guest code the problem is easy (for instance you could just go back to the old glibc approach). But we need to run the code as it stands. + + +any solution? trying to emulate a closed source amd64 app on my raspberry and i'm getting this error with qemu 5.2.0-rc4 and glibc 2.27. + + +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/140 + + diff --git a/results/classifier/zero-shot/108/none/1680 b/results/classifier/zero-shot/108/none/1680 new file mode 100644 index 000000000..8efe577c4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1680 @@ -0,0 +1,117 @@ +other: 0.528 +KVM: 0.461 +graphic: 0.428 +device: 0.399 +performance: 0.397 +permissions: 0.379 +debug: 0.337 +boot: 0.328 +PID: 0.319 +vnc: 0.310 +semantic: 0.299 +network: 0.266 +socket: 0.265 +files: 0.181 + +qemu-system-x86_64: ../softmmu/memory.c:1111: memory_region_transaction_commit: Assertion `qemu_mutex_iothread_locked()' failed. +Description of problem: +While testing master build, I have the following crash on shutdown of the VM: +qemu-system-x86_64: ../softmmu/memory.c:1111: memory_region_transaction_commit: Assertion `qemu_mutex_iothread_locked()' failed. +Steps to reproduce: +1. Run VM +2. Once booted, do poweroff inside the Linux VM +3. When poweroff completes, qemu crashes. +Additional information: +```(gdb) bt full +#0 0x00007ffff29edacf in raise () at /lib64/libc.so.6 +#1 0x00007ffff29c0ea5 in abort () at /lib64/libc.so.6 +#2 0x00007ffff29c0d79 in _nl_load_domain.cold.0 () at /lib64/libc.so.6 +#3 0x00007ffff29e6426 in () at /lib64/libc.so.6 +#4 0x0000555555bed6d3 in memory_region_transaction_commit () at ../softmmu/memory.c:1111 + as = <optimized out> + __PRETTY_FUNCTION__ = "memory_region_transaction_commit" +#5 0x0000555555bef2bf in memory_region_add_eventfd (mr=mr@entry=0x555557c318a0, addr=<optimized out>, size=size@entry=0, match_data=<optimized out>, data=<optimized out>, e=<optimized out>) at ../softmmu/memory.c:2583 + mrfd = {addr = {start = 0, size = 0}, match_data = false, data = 0, e = 0x555557c41aa4} + i = <optimized out> +#6 0x0000555555a2c85c in virtio_pci_ioeventfd_assign (d=0x555557c30a00, notifier=0x555557c41aa4, n=0, assign=<optimized out>) at ../hw/virtio/virtio-pci.c:347 + proxy = 0x555557c30a00 + vdev = <optimized out> + vq = <optimized out> + legacy = true + modern = <optimized out> + fast_mmio = true + modern_pio = false + modern_mr = <optimized out> + modern_notify_mr = 0x555557c319c0 + legacy_mr = 0x555557c31430 + modern_addr = <optimized out> +#7 0x0000555555a2be78 in virtio_bus_set_host_notifier (bus=0x555557c38d50, n=n@entry=0, assign=assign@entry=true) at ../hw/virtio/virtio-bus.c:296 + vdev = <optimized out> + k = 0x555556a7b620 + proxy = 0x555557c30a00 + vq = 0x555557c41a30 + notifier = 0x555557c41aa4 + r = <optimized out> + __func__ = "virtio_bus_set_host_notifier" +#8 0x0000555555ba1595 in virtio_scsi_set_host_notifier (s=s@entry=0x555557c38dd0, n=n@entry=0, vq=<optimized out>) at /root/qemu/include/hw/virtio/virtio-bus.h:35 + qbus = <optimized out> + rc = <optimized out> +#9 0x0000555555ba1860 in virtio_scsi_dataplane_start (vdev=<optimized out>) at ../hw/scsi/virtio-scsi-dataplane.c:130 + i = <optimized out> + rc = <optimized out> + vq_init_count = 0 + qbus = 0x555557c38d50 + k = 0x555556a7b620 + vs = 0x555557c38dd0 + s = 0x555557c38dd0 +#10 0x0000555555a2bbd2 in virtio_bus_start_ioeventfd (bus=0x555557c38d50) at ../hw/virtio/virtio-bus.c:236 + k = <optimized out> + proxy = 0x555557c30a00 + vdev = 0x555557c38dd0 + vdc = 0x555556a19cc0 + r = <optimized out> + __func__ = "virtio_bus_start_ioeventfd" +#11 0x0000555555bc0739 in virtio_device_start_ioeventfd (vdev=vdev@entry=0x555557c38dd0) at ../hw/virtio/virtio.c:3741 + qbus = <optimized out> + vbus = <optimized out> +#12 0x0000555555b9fc80 in virtio_scsi_defer_to_dataplane (s=0x555557c38dd0) at ../hw/scsi/virtio-scsi.c:614 + s = 0x555557c38dd0 +#13 0x0000555555b9fc80 in virtio_scsi_defer_to_dataplane (s=0x555557c38dd0) at ../hw/scsi/virtio-scsi.c:608 + s = 0x555557c38dd0 +#14 0x0000555555b9fc80 in virtio_scsi_handle_event (vdev=<optimized out>, vq=<optimized out>) at ../hw/scsi/virtio-scsi.c:1011 + s = 0x555557c38dd0 +#15 0x0000555555bba2af in virtio_queue_notify_vq (vq=0x555557c41ac8) at ../hw/virtio/virtio.c:2248 + vdev = 0x555557c38dd0 +#16 0x0000555555de7b08 in aio_dispatch_handler (ctx=ctx@entry=0x555556c2c130, node=0x555557ffbff0) at ../util/aio-posix.c:356 + progress = false + poll_ready = true + revents = <optimized out> +#17 0x0000555555de861c in aio_dispatch_ready_handlers (ready_list=0x7fffde952fe8, ctx=0x555556c2c130) at ../util/aio-posix.c:401 + progress = false + node = <optimized out> + ready_list = {lh_first = 0x0} + progress = true + use_notify_me = <optimized out> + timeout = <optimized out> + start = <optimized out> + __PRETTY_FUNCTION__ = "aio_poll" +#18 0x0000555555de861c in aio_poll (ctx=0x555556c2c130, blocking=blocking@entry=true) at ../util/aio-posix.c:723 + ready_list = {lh_first = 0x0} + progress = true + use_notify_me = <optimized out> + timeout = <optimized out> + start = <optimized out> + __PRETTY_FUNCTION__ = "aio_poll" +#19 0x0000555555ca9ae6 in iothread_run (opaque=opaque@entry=0x555556943200) at ../iothread.c:63 + iothread = 0x555556943200 +#20 0x0000555555deaf6a in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 + __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {93825016192880, 1094026140696841148, 140737488341294, 140737488341295, 140737488341440, 140736927707584, 6520036150746942396, 1094028099712322492}, __mask_was_saved = 0}}, __pad = {0x7fffde953110, 0x0, 0x0, 0x0}} + __cancel_routine = 0x555555deafc0 <qemu_thread_atexit_notify> + __not_first_call = <optimized out> + qemu_thread_args = <optimized out> + start_routine = 0x555555ca9aa0 <iothread_run> + arg = 0x555556943200 + r = <optimized out> +#21 0x00007ffff2d6c1ca in start_thread () at /lib64/libpthread.so.0 +#22 0x00007ffff29d8e73 in clone () at /lib64/libc.so.6 +``` diff --git a/results/classifier/zero-shot/108/none/1683 b/results/classifier/zero-shot/108/none/1683 new file mode 100644 index 000000000..0bc2646e5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1683 @@ -0,0 +1,16 @@ +device: 0.485 +graphic: 0.355 +performance: 0.219 +permissions: 0.179 +semantic: 0.162 +PID: 0.127 +debug: 0.100 +network: 0.083 +boot: 0.044 +files: 0.018 +socket: 0.012 +vnc: 0.006 +other: 0.004 +KVM: 0.001 + +How to run qemu inside ubuntu:latest docker container? diff --git a/results/classifier/zero-shot/108/none/1701808 b/results/classifier/zero-shot/108/none/1701808 new file mode 100644 index 000000000..1a2327bab --- /dev/null +++ b/results/classifier/zero-shot/108/none/1701808 @@ -0,0 +1,54 @@ +graphic: 0.232 +semantic: 0.225 +device: 0.116 +PID: 0.097 +performance: 0.058 +vnc: 0.050 +network: 0.046 +other: 0.043 +debug: 0.035 +socket: 0.034 +permissions: 0.032 +boot: 0.020 +KVM: 0.018 +files: 0.016 + +stack smashing in or after recvmsg system call in aarch64 user mode + +A program that invokes recvmsg aborts with "*** stack smashing detected ***" when run in qemu-aarch64 (user mode), but works fine when running on native aarch64 hardware. + +How to reproduce: +$ aarch64-linux-gnu-gcc-5 -O -Wall /media/develdata/devel/qemu-bug/testpassfd.c -static -DEXTRA_SPACE=0 +$ QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-aarch64 ./a.out +*** stack smashing detected ***: ./a.out terminated +qemu: uncaught target signal 6 (Aborted) - core dumped + +On native aarch64 hardware: +$ ./a.out +$ echo $? +0 + +The parameter EXTRA_SPACE can be used to add additional space to the array that receives the recvmsg data. With -DEXTRA_SPACE=9 (or larger), the program runs fine. Which suggests that recvmsg is storing up to 9 bytes more than allowed in memory. + + + + + +Likewise for 32-bit arm: +$ ~/inst-qemu/2.9.0/bin/qemu-arm ./a.arm +*** stack smashing detected ***: ./a.arm terminated +qemu: uncaught target signal 6 (Aborted) - core dumped + + +The behaviour in qemu-2.10 is the same as in qemu-2.9. + +The behaviour in qemu-2.11 is the same as in qemu-2.9. + +This should be fixed by http://patchwork.ozlabs.org/patch/849170/ I think. + + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7174970a94df10ee84143 + +Confirmed: It's fixed in qemu-2.12. + diff --git a/results/classifier/zero-shot/108/none/1701973 b/results/classifier/zero-shot/108/none/1701973 new file mode 100644 index 000000000..ffc2337a2 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1701973 @@ -0,0 +1,53 @@ +performance: 0.508 +other: 0.408 +semantic: 0.360 +socket: 0.337 +device: 0.335 +network: 0.278 +PID: 0.234 +graphic: 0.228 +files: 0.227 +permissions: 0.225 +boot: 0.198 +vnc: 0.177 +debug: 0.157 +KVM: 0.149 + +pread does not work right under qemu-sh4 + +The pread system call returns a wrong value in some case, in a program running under qemu-sh4 (version 2.9.0). + +How to reproduce: +- Compile the program: + sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pread test-pread.c +- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pread + +Expected output: +ret=1 errno=0 + +Actual output: +ret=0 errno=2 +test-pread.c:44: assertion 'ret == 1' failed +qemu: uncaught target signal 6 (Aborted) - core dumped + + + + + +In case it matters: My host platform is Linux/x86_64. + +The behaviour in qemu-2.10 is the same as in qemu-2.9. + +This might be related to this fix: + +> https://git.qemu.org/?p=qemu.git;a=commit;h=8bf8e9df4a7d82c7a47cc961c9cdee1615595de0 + +FWIW, if you're interested in sh4, please join #debian-ports on OFTC and subscribe to the debian-superh mailing list. We're doing lots of sh4 development and testing QEMU in Debian. + +With qemu-2.11: +$ ~/inst-qemu/2.11.0/bin/qemu-sh4 test-pread +ret=1 errno=2 + +The value of errno is actually irrelevant here. So, the bug is fixed. + diff --git a/results/classifier/zero-shot/108/none/1701974 b/results/classifier/zero-shot/108/none/1701974 new file mode 100644 index 000000000..0396323b0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1701974 @@ -0,0 +1,52 @@ +semantic: 0.404 +device: 0.378 +files: 0.307 +vnc: 0.293 +performance: 0.277 +PID: 0.271 +network: 0.247 +graphic: 0.227 +socket: 0.226 +other: 0.196 +boot: 0.150 +KVM: 0.135 +permissions: 0.130 +debug: 0.109 + +pwrite does not work right under qemu-sh4 + +The pwrite system call has no effect when writing to a non-zero file position, in a program running under qemu-sh4 (version 2.9.0). + +How to reproduce: +- Compile the program: + sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pwrite test-pwrite.c +- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pwrite + +Expected output: +buf = 01W3456789 + +Actual output: +buf = 0123456789 +test-pwrite.c:56: assertion 'strcmp ("01W3456789",buf) == 0' failed +qemu: uncaught target signal 6 (Aborted) - core dumped + + + + + +In case it matters: My host platform is Linux/x86_64. + +The behaviour in qemu-2.10 is the same as in qemu-2.9. + +This might be related to this fix: + +> https://git.qemu.org/?p=qemu.git;a=commit;h=8bf8e9df4a7d82c7a47cc961c9cdee1615595de0 + +FWIW, if you're interested in sh4, please join #debian-ports on OFTC and subscribe to the debian-superh mailing list. We're doing lots of sh4 development and testing QEMU in Debian. + +Works fine in qemu-2.11: +$ ~/inst-qemu/2.11.0/bin/qemu-sh4 test-pwrite +buf = 01W3456789 + + diff --git a/results/classifier/zero-shot/108/none/1703147 b/results/classifier/zero-shot/108/none/1703147 new file mode 100644 index 000000000..fe3ef3998 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1703147 @@ -0,0 +1,75 @@ +files: 0.485 +device: 0.471 +socket: 0.466 +PID: 0.428 +debug: 0.317 +semantic: 0.316 +network: 0.306 +other: 0.303 +performance: 0.270 +vnc: 0.214 +graphic: 0.177 +boot: 0.177 +permissions: 0.172 +KVM: 0.144 + +Xfer:features:read truncating xml sent to gdb frontends + +Around line 1326 in gdbstub.c: + + if (len > (MAX_PACKET_LENGTH - 5) / 2) + len = (MAX_PACKET_LENGTH - 5) / 2; + +is truncating processor reg description xml files longer than 2045 bytes. Deleting these lines works for my immediate need, but they seem to be trying to fix some buffer overrun condition so I won't offer a patch until we understand their purpose. + +On 8 July 2017 at 22:19, Duane Voth <email address hidden> wrote: +> Around line 1326 in gdbstub.c: +> +> if (len > (MAX_PACKET_LENGTH - 5) / 2) +> len = (MAX_PACKET_LENGTH - 5) / 2; +> +> is truncating processor reg description xml files longer than 2045 +> bytes. Deleting these lines works for my immediate need, but they seem +> to be trying to fix some buffer overrun condition so I won't offer a +> patch until we understand their purpose. + +Those lines prevent the packet we're constructing overrunning +the buf[] array (in the worst case the packet encoding could +use 2 bytes of buffer for every byte of payload). It's probably +working for you without them because (a) the XML payload doesn't +come near the worst-case and (b) buf[] is followed on the stack +by mem_buf[] which happens to be unused here so overrunning into +it has no visible harmful effects. + +Truncating the XML is clearly not what we want though so we +should do something more intelligent... + +thanks +-- PMM + + +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.] + +Problematic code now around lines 2221 (in handle_query_xfer_features) ... lol I'm the only one impacted ... all the large register set cpus can be affected. + + +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/458 + + diff --git a/results/classifier/zero-shot/108/none/1704186 b/results/classifier/zero-shot/108/none/1704186 new file mode 100644 index 000000000..14df49759 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1704186 @@ -0,0 +1,27 @@ +device: 0.447 +other: 0.231 +graphic: 0.162 +semantic: 0.130 +vnc: 0.066 +boot: 0.056 +network: 0.048 +performance: 0.041 +socket: 0.031 +debug: 0.022 +permissions: 0.014 +PID: 0.013 +KVM: 0.011 +files: 0.007 + +no option for handling ^C in stdio + +There is no way to tell qemu to handle (or not) ^C on standard input. + +This makes using serial console on stdio needlessly annoying and difficult. + +The code is there - depending on how you set up the console it may handle the signal or not. + +That's completely backwards. The behavior should be the same regardless of how you set up console *and* there should be a separate option for handling ^C. + +You can select the behavior of ^C when specifying "-chardev stdio,signal=[on|off]". See also https://www.qemu.org/docs/master/system/invocation.html#hxtool-6 + diff --git a/results/classifier/zero-shot/108/none/1706058 b/results/classifier/zero-shot/108/none/1706058 new file mode 100644 index 000000000..bd02ed46a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1706058 @@ -0,0 +1,112 @@ +KVM: 0.392 +device: 0.172 +vnc: 0.159 +other: 0.144 +performance: 0.112 +debug: 0.109 +PID: 0.104 +boot: 0.102 +network: 0.099 +permissions: 0.091 +socket: 0.086 +semantic: 0.084 +graphic: 0.079 +files: 0.075 + +Windows VM crashes when restoring from file if balloon stats polling is enabled + +[Impact] + + * Windows VMs BSOD when restoring from QEMUfile or during live migration if the virtio balloon stats polling is enabled. + +[Test Case] + + * Install a Windows VM with virtio balloon drivers + * Start the VM and enable stats polling [1] + * Save the VM to savefile [2] + * Restore the VM [3] + * Enable stats polling [1] and VM will BSOD + +QMP examples: + [1] {"execute":"qom-set","arguments":{"path":"//machine/i440fx/pci.0/child[7]","property":"guest-stats-polling-interval","value":10}} + [2] {"execute": "migrate", "arguments": {"uri":"exec:gzip -c > /storage/cases/VM/savefiles/testVM3save.gz"}} + [3] {"execute":"migrate-incoming","arguments":{"uri":"exec:gzip -c -d /storage/cases/VM/savefiles/testVM3save.gz"}} + +[Other Info] + + * This has been fixed upstream with commit 4a1e48becab81020adfb74b22c76a595f2d02a01 + +[Regression Potential] + + * + +Please make sure to use the right target for downstream bugs ==> Re-assigned this to qemu-ubuntu + +Thanks Thomas! + +To confirm the issue described in the original fix, I traced the virtio balloon subsystem (using QEMU simpletracing) while the VM: + +1.) Loaded from a QEMUFile +virtio_set_status 0.000 pid=6248 vdev=0x55dcc49cf968 val=0x0 +balloon_event 31433104.748 pid=6248 opaque=0x55dcc49cf968 addr=0x100000000 +virtio_balloon_to_target 341.343 pid=6248 target=0x100000000 num_pages=0x0 +virtio_set_status 5017492.910 pid=6248 vdev=0x55dcc49cf968 val=0x7 +# Driver negotiation finished; running balloon_stats_cb() -> virtqueue_push() +virtqueue_fill 16176215.480 pid=6248 vq=0x55dcc4a4c9b0 elem=0x55dcc49cfa98 len=0x0 idx=0x0 +virtqueue_flush 6.821 pid=6248 vq=0x55dcc4a4c9b0 count=0x1 +virtqueue_flush_vt 2.050 pid=6248 old=0xc4 new=0xc5 inuse=0x1 +virtio_notify 1.380 pid=6248 vdev=0x55dcc49cf968 vq=0x55dcc4a4c9b0 + +Here stats_vq_offset is 0 and elem->index is invalid, making the guest BSOD. + +2.) Booted normally +... +virtio_set_status 0.754 pid=1133 vdev=0x55c2aec27888 val=0x0 +virtio_set_status 21.646 pid=1133 vdev=0x55c2aec27888 val=0x3 +virtio_set_status 297.769 pid=1133 vdev=0x55c2aec27888 val=0x7 +virtio_queue_notify 20.924 pid=1133 vdev=0x55c2aec27888 n=0x2 vq=0x55c2ae39cb60 +virtqueue_pop 29.931 pid=1133 vq=0x55c2ae39cb60 elem=0x55c2aec279b8 in_num=0x0 out_num=0x1 +virtio_balloon_get_config 357.561 pid=1133 num_pages=0x0 acutal=0x0 +virtio_balloon_get_config 10.239 pid=1133 num_pages=0x0 acutal=0x0 +virtio_balloon_get_config 2.862 pid=1133 num_pages=0x0 acutal=0x0 +virtio_balloon_get_config 2.761 pid=1133 num_pages=0x0 acutal=0x0 +virtio_balloon_set_config 171.747 pid=1133 acutal=0x0 oldacutal=0x0 +virtio_balloon_set_config 135.158 pid=1133 acutal=0x0 oldacutal=0x0 +virtio_balloon_set_config 103.806 pid=1133 acutal=0x0 oldacutal=0x0 +virtio_balloon_set_config 95.435 pid=1133 acutal=0x0 oldacutal=0x0 +# Driver negotiation finished; running balloon_stats_cb() -> virtqueue_push() +virtqueue_fill 24115244.041 pid=1133 vq=0x55c2ae39cb60 elem=0x55c2aec279b8 len=0x3c idx=0x0 +virtqueue_flush 7.069 pid=1133 vq=0x55c2ae39cb60 count=0x1 +virtqueue_lol 1.712 pid=1133 old=0x0 new=0x1 inuse=0x1 +virtio_notify 1.120 pid=1133 vdev=0x55c2aec27888 vq=0x55c2ae39cb60 +virtio_queue_notify 1907.429 pid=1133 vdev=0x55c2aec27888 n=0x2 vq=0x55c2ae39cb60 +virtqueue_pop 9.840 pid=1133 vq=0x55c2ae39cb60 elem=0x55c2aec279b8 in_num=0x0 out_num=0x1 +... + +Here stats_vq_offset is 0x3c (the size of stats_vq_elem), and the request proceeds without problem. + +I'm currently working on the SRU + +Thanks Victor for bringing this up and working on it! + +For Documentation, the fix is in qemu 2.8, therefore >=Zesty is good in regard to the bug. + +Parts of the description sounded familiar to me and I found bug 1604010 - this was a rather ugly update regression, so you might want to read through it just to know that context as well. + +Once you have a ppa working please ping me here or on IRC (cpaelzer) so I can give it some extra regressions checks before we push things to the SRU queue. + +Hi Victor, +I'm currently updating bugs on our virt-stack that are open but seem dormant. + +Is work on this going on or is Xenial/Trusty activity that was nominated dropped for a reason? +As I can't reproduce lacking the special guest and env that was needed I'd rely on you to do so. +And since you drove the other fixes for the cloud archive you have the needed changes. + +For now I'm setting these tasks to incomplete to time them out if no feedback was provided when I clear out old bugs the next time. + +Hi Christian, + +Sorry for the lack of updates, I've been trying to reproduce this behavior using Linux guests and it seems that those VMs work perfectly. I'm currently checking the virtio balloon driver for Windows, as it might be the real culprit of the VM crash. + +I'll update the case with my findings, thanks! + diff --git a/results/classifier/zero-shot/108/none/1711602 b/results/classifier/zero-shot/108/none/1711602 new file mode 100644 index 000000000..09924767f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1711602 @@ -0,0 +1,948 @@ +KVM: 0.584 +device: 0.551 +semantic: 0.526 +other: 0.486 +vnc: 0.474 +graphic: 0.468 +network: 0.467 +PID: 0.443 +permissions: 0.410 +performance: 0.366 +debug: 0.353 +files: 0.341 +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/zero-shot/108/none/1715007 b/results/classifier/zero-shot/108/none/1715007 new file mode 100644 index 000000000..872ae78e0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1715007 @@ -0,0 +1,35 @@ +socket: 0.569 +semantic: 0.536 +graphic: 0.520 +device: 0.469 +network: 0.458 +files: 0.282 +performance: 0.251 +vnc: 0.209 +debug: 0.172 +PID: 0.112 +permissions: 0.103 +KVM: 0.101 +boot: 0.095 +other: 0.063 + +hw/block/onenand.c:520: dead code ? + +qemu/hw/block/onenand.c:520] -> [qemu/hw/block/onenand.c:521]: (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; + } + +I am not sure if the if condition can be merely deleted, or something more +complex needs to be implemented. + +Recent qemu trunk. + +Fix has now been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=dbfa934106d22402d + diff --git a/results/classifier/zero-shot/108/none/1718295 b/results/classifier/zero-shot/108/none/1718295 new file mode 100644 index 000000000..d40fcff13 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1718295 @@ -0,0 +1,262 @@ +other: 0.323 +graphic: 0.273 +KVM: 0.199 +permissions: 0.156 +semantic: 0.139 +device: 0.137 +vnc: 0.100 +network: 0.092 +boot: 0.090 +debug: 0.085 +performance: 0.084 +PID: 0.077 +files: 0.073 +socket: 0.048 + +Live migration fails with qemu-img >= 2.10: "Failed to get shared "write" lock\nIs another process using the image?" + +Looks like this is pretty new: + +http://logs.openstack.org/01/503601/7/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/b19b77c/logs/screen-n-api.txt.gz?level=TRACE#_Sep_19_17_47_11_508623 + +Sep 19 17:47:11.508623 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: ERROR nova.api.openstack.extensions [None req-e31fde7b-317f-4db9-b225-10b6e11b2dff tempest-LiveMigrationTest-1678596498 tempest-LiveMigrationTest-1678596498] Unexpected exception in API method: MigrationError_Remote: Migration error: Disk info file is invalid: qemu-img failed to execute on /opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk : Unexpected error while running command. +Sep 19 17:47:11.508805 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Command: /usr/bin/python2 -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info /opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk +Sep 19 17:47:11.508946 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Exit code: 1 +Sep 19 17:47:11.509079 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Stdout: u'' +Sep 19 17:47:11.509233 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Stderr: u'qemu-img: Could not open \'/opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk\': Failed to get shared "write" lock\nIs another process using the image?\n' +Sep 19 17:47:11.509487 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Traceback (most recent call last): +Sep 19 17:47:11.509649 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 160, in _process_incoming +Sep 19 17:47:11.509789 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: res = self.dispatcher.dispatch(message) +Sep 19 17:47:11.510231 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 222, in dispatch +Sep 19 17:47:11.510418 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: return self._do_dispatch(endpoint, method, ctxt, args) +Sep 19 17:47:11.510555 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 192, in _do_dispatch +Sep 19 17:47:11.510687 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: result = func(ctxt, **new_args) +Sep 19 17:47:11.510829 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/exception_wrapper.py", line 76, in wrapped +Sep 19 17:47:11.510959 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: function_name, call_dict, binary) +Sep 19 17:47:11.511194 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ +Sep 19 17:47:11.511713 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: self.force_reraise() +Sep 19 17:47:11.511852 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise +Sep 19 17:47:11.512037 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: six.reraise(self.type_, self.value, self.tb) +Sep 19 17:47:11.512687 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/exception_wrapper.py", line 67, in wrapped +Sep 19 17:47:11.516811 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: return f(self, context, *args, **kw) +Sep 19 17:47:11.516966 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/compute/utils.py", line 876, in decorated_function +Sep 19 17:47:11.517110 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: return function(self, context, *args, **kwargs) +Sep 19 17:47:11.525392 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/compute/manager.py", line 217, in decorated_function +Sep 19 17:47:11.525526 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: kwargs['instance'], e, sys.exc_info()) +Sep 19 17:47:11.525654 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ +Sep 19 17:47:11.525783 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: self.force_reraise() +Sep 19 17:47:11.525909 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise +Sep 19 17:47:11.526057 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: six.reraise(self.type_, self.value, self.tb) +Sep 19 17:47:11.526186 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/compute/manager.py", line 205, in decorated_function +Sep 19 17:47:11.526314 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: return function(self, context, *args, **kwargs) +Sep 19 17:47:11.529795 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/compute/manager.py", line 5378, in check_can_live_migrate_source +Sep 19 17:47:11.529952 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: block_device_info) +Sep 19 17:47:11.530083 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 5960, in check_can_live_migrate_source +Sep 19 17:47:11.530446 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: block_device_info) +Sep 19 17:47:11.530587 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 6060, in _assert_dest_node_has_enough_disk +Sep 19 17:47:11.530720 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: disk_infos = self._get_instance_disk_info(instance, block_device_info) +Sep 19 17:47:11.531945 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 7254, in _get_instance_disk_info +Sep 19 17:47:11.532099 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: block_device_info) +Sep 19 17:47:11.532234 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 7222, in _get_instance_disk_info_from_config +Sep 19 17:47:11.532366 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: backing_file = libvirt_utils.get_disk_backing_file(path) +Sep 19 17:47:11.532496 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/utils.py", line 197, in get_disk_backing_file +Sep 19 17:47:11.532627 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: backing_file = images.qemu_img_info(path, format).backing_file +Sep 19 17:47:11.532755 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/images.py", line 72, in qemu_img_info +Sep 19 17:47:11.532896 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: raise exception.InvalidDiskInfo(reason=msg) +Sep 19 17:47:11.533373 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: InvalidDiskInfo: Disk info file is invalid: qemu-img failed to execute on /opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk : Unexpected error while running command. +Sep 19 17:47:11.534451 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Command: /usr/bin/python2 -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info /opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk +Sep 19 17:47:11.534670 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Exit code: 1 +Sep 19 17:47:11.534902 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Stdout: u'' +Sep 19 17:47:11.541303 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Stderr: u'qemu-img: Could not open \'/opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk\': Failed to get shared "write" lock\nIs another process using the image?\n' + +http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Unexpected%20exception%20in%20API%20method%3A%20MigrationError_Remote%3A%20Migration%20error%3A%20Disk%20info%20file%20is%20invalid%3A%20qemu-img%20failed%20to%20execute%20on%5C%22%20AND%20tags%3A%5C%22screen-n-api.txt%5C%22&from=7d + +252 hits starting on 9/19, check and gate, all failures. + +http://tinyurl.com/lgnq48d + + +I don't see any related nova changes in the last 48 hours that look like they could cause this. I wonder if there is a new qemu package or something. + +qemu-system 1:2.10+dfsg-0ubuntu1~cloud0 + +qemu-system 1:2.10+dfsg-0ubuntu1~cloud0 was released on 9/5 so we've already been using it for a couple of weeks. + +It's probably this change to devstack to use the pike cloud archive: + +https://review.openstack.org/#/c/501224/ + +Fix proposed to branch: master +Review: https://review.openstack.org/505446 + +See bug 1718133 + +Reviewed: https://review.openstack.org/505446 +Committed: https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=ee22ca8373abd3b5a4c44a9c5c4da39c511195c8 +Submitter: Jenkins +Branch: master + +commit ee22ca8373abd3b5a4c44a9c5c4da39c511195c8 +Author: Matt Riedemann <email address hidden> +Date: Wed Sep 20 00:29:36 2017 +0000 + + Revert "Update to using pike cloud-archive" + + This reverts commit a7e9a5d447b3eeacfb52d7ddc94445058a8d6fd1. + + The jobs that run live migration tests are failing at about + a rate of 50% since this merged. There are no recent changes + to nova in the last 24 hours that are related to live + migration, and this is failing on the master branch only, + so I suspect the failures are due to new qemu packages + getting pulled in from this change. + + Change-Id: Ic8481539c6a0cc7af08a736a625b672979435908 + Closes-Bug: #1718295 + + +This is a behavioural change in qemu for 2.10 - looks like 'qemu-img info' needs to be passed a '--force-share' option to allow it to read a disk file for a running instance. + +This appears like it might be an issue with the ppa in pike + +Since it is a wanted behavioral change in upstream qemu setting that task to "Won't Fix" unless we come up with a reason to convince qemu to do so. +Once might argue that info should imply force-share or such, but unless we do so make clear that no qemu change is expected. +James already mentioned bug 1718133. + +@James and Matt - should we dup one of those onto the other? + +Distro patch to unblock Ubuntu Pike UCA and Artful (needs conditional check for general consumption). + +Setting Nova bug task back to 'New' as I think we do need to accommodate this behavioural change in qemu. + +Fix proposed to branch: master +Review: https://review.openstack.org/505673 + +Related fix proposed to branch: master +Review: https://review.openstack.org/505674 + +Fix proposed to branch: master +Review: https://review.openstack.org/505748 + +Change abandoned by James Page (<email address hidden>) on branch: master +Review: https://review.openstack.org/505748 +Reason: Abandoning in preference of alternative fix. + +Reviewed: https://review.openstack.org/505673 +Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=807579755c4a116309eca5b2bcdbab9d1f393bab +Submitter: Zuul +Branch: master + +commit 807579755c4a116309eca5b2bcdbab9d1f393bab +Author: Matt Riedemann <email address hidden> +Date: Wed Sep 20 10:44:11 2017 -0400 + + Support qemu >= 2.10 + + Qemu 2.10 added the requirement of a --force-share flag to qemu-img + info when reading information about a disk that is in use by a + guest. We do this a lot in Nova for operations like gathering + information before live migration. + + Up until this point all qemu/libvirt version matching has been solely + inside the libvirt driver, however all the image manip code was moved + out to nova.virt.images. We need the version of QEMU available there. + + This does it by initializing that version on driver init host. The net + effect is also that broken libvirt connections are figured out + earlier, as there is an active probe for this value. + + Co-Authored-By: Sean Dague <email address hidden> + + Change-Id: Iae2962bb86100f03fd3ad9aac3767da876291e74 + Closes-Bug: #1718295 + + +Reviewed: https://review.openstack.org/505674 +Committed: https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=917ad0998be8c48bfcc0e3031bc1b75cd9ed1927 +Submitter: Zuul +Branch: master + +commit 917ad0998be8c48bfcc0e3031bc1b75cd9ed1927 +Author: Matt Riedemann <email address hidden> +Date: Wed Sep 20 14:46:48 2017 +0000 + + Update to using pike cloud-archive + + This reverts commit ee22ca8373abd3b5a4c44a9c5c4da39c511195c8 + + Depends-On: Iae2962bb86100f03fd3ad9aac3767da876291e74 + + Change-Id: I4d5fa052bdc5eef1795f6507589e2eaf4e093e23 + Related-Bug: #1718295 + + +Is this going to be backported to Pike, I ran into the same issue with openstack-ansible in Pike + +Fix proposed to branch: stable/pike +Review: https://review.openstack.org/509774 + +Change abandoned by Kevin Lefevre (<email address hidden>) on branch: stable/pike +Review: https://review.openstack.org/509774 +Reason: sorry + +Reviewed: https://review.openstack.org/509774 +Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=5e9508b77f86f1fadb173a071e2519aad24534f9 +Submitter: Jenkins +Branch: stable/pike + +commit 5e9508b77f86f1fadb173a071e2519aad24534f9 +Author: Matt Riedemann <email address hidden> +Date: Wed Sep 20 10:44:11 2017 -0400 + + Support qemu >= 2.10 + + Qemu 2.10 added the requirement of a --force-share flag to qemu-img + info when reading information about a disk that is in use by a + guest. We do this a lot in Nova for operations like gathering + information before live migration. + + Up until this point all qemu/libvirt version matching has been solely + inside the libvirt driver, however all the image manip code was moved + out to nova.virt.images. We need the version of QEMU available there. + + This does it by initializing that version on driver init host. The net + effect is also that broken libvirt connections are figured out + earlier, as there is an active probe for this value. + + Co-Authored-By: Sean Dague <email address hidden> + + Change-Id: Iae2962bb86100f03fd3ad9aac3767da876291e74 + Closes-Bug: #1718295 + (cherry picked from commit 807579755c4a116309eca5b2bcdbab9d1f393bab) + + +This issue was fixed in the openstack/nova 17.0.0.0b1 development milestone. + +This issue was fixed in the openstack/nova 16.0.2 release. + +I think I am experiencing this issue on 15.1.13 + +If it's not going to be backported to O can anyone suggest a workaround? + +@Filippo: your options are (1) use an older version of QEMU or (2) backport the change to your Ocata-based deployment and run with it out of tree. + +Related fix proposed to branch: stable/pike +Review: https://review.openstack.org/536798 + +Change abandoned by Lee Yarwood (<email address hidden>) on branch: stable/pike +Review: https://review.openstack.org/536798 + +hi , because of power outage, Most of our compute nodes unexpectedly shut down and now I can't start our instances. I am getting "Failed to get "write" lock Is another process using the image?" error. Full error log is http://paste.openstack.org/show/754107/. My environment is OpenStack Pike and Instances are on a nfs shared storage. Nova version is 16.1.6.dev2. This fix can not solve this problem completely. What would you suggest for solve this problem ? + +Maybe your files are still in locked state on the NFS system. +That you chould check with qemu-img operations, no need to start the guest. +If they are you might need to remove that lock bit (not sure how atm). + +Fix proposed to branch: stable/ocata +Review: https://review.opendev.org/693851 + +Change abandoned by "Elod Illes <email address hidden>" on branch: stable/ocata +Review: https://review.opendev.org/c/openstack/nova/+/693851 +Reason: stable/ocata of openstack/nova transitioned to End of Life ( https://review.opendev.org/c/openstack/releases/+/795664 ), to be able to delete the branch we need to abandon all open patches on the branch. + diff --git a/results/classifier/zero-shot/108/none/1720971 b/results/classifier/zero-shot/108/none/1720971 new file mode 100644 index 000000000..10c498b3e --- /dev/null +++ b/results/classifier/zero-shot/108/none/1720971 @@ -0,0 +1,29 @@ +graphic: 0.586 +network: 0.573 +other: 0.551 +socket: 0.521 +device: 0.499 +semantic: 0.301 +performance: 0.279 +vnc: 0.247 +files: 0.198 +KVM: 0.185 +debug: 0.120 +boot: 0.118 +permissions: 0.096 +PID: 0.068 + +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/zero-shot/108/none/1728657 b/results/classifier/zero-shot/108/none/1728657 new file mode 100644 index 000000000..eb6b487ca --- /dev/null +++ b/results/classifier/zero-shot/108/none/1728657 @@ -0,0 +1,136 @@ +KVM: 0.252 +other: 0.233 +vnc: 0.182 +device: 0.174 +files: 0.158 +graphic: 0.147 +performance: 0.138 +PID: 0.133 +permissions: 0.129 +semantic: 0.126 +boot: 0.121 +debug: 0.112 +socket: 0.109 +network: 0.098 + +qemu-io: block/qcow2-cluster.c:1109: handle_copied: Assertion failed + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached file test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "write 4105728 2791936" + +from gdb: +(gdb) bt +#0 0x00003fffb17eeff0 in raise () from /lib64/libc.so.6 +#1 0x00003fffb17f136c in abort () from /lib64/libc.so.6 +#2 0x00003fffb17e4c44 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00003fffb17e4d34 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000100631fc in handle_copied (bs=0x42ba9ad0, guest_offset=4210688, host_offset=0x3fffaf4bfab0, bytes=0x3fffaf4bfab8, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1108 +#5 0x0000000010064118 in qcow2_alloc_cluster_offset (bs=0x42ba9ad0, offset=4194304, bytes=0x3fffaf4bfb4c, host_offset=0x3fffaf4bfb58, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1498 +#6 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x42ba9ad0, offset=4194304, bytes=2703360, qiov=0x3fffc7cc9ee0, flags=0) at block/qcow2.c:1919 +#7 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x42ba9ad0, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=16) at block/io.c:898 +#8 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x42bb8250, req=0x3fffaf4bfdd8, offset=4105728, bytes=2791936, align=1, qiov=0x3fffc7cc9ee0, flags=16) + at block/io.c:1440 +#9 0x00000000100ac4ac in bdrv_co_pwritev (child=0x42bb8250, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/io.c:1691 +#10 0x000000001008da0c in blk_co_pwritev (blk=0x42b99410, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +#11 0x000000001008db68 in blk_write_entry (opaque=0x3fffc7cc9ef8) at block/block-backend.c:1110 +#12 0x00000000101aa444 in coroutine_trampoline (i0=1119572144, i1=0) at util/coroutine-ucontext.c:79 +#13 0x00003fffb1802b9c in makecontext () from /lib64/libc.so.6 +#14 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00003fffb17eeff0 in raise () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00003fffb17f136c in abort () from /lib64/libc.so.6 +No symbol table info available. +#2 0x00003fffb17e4c44 in __assert_fail_base () from /lib64/libc.so.6 +No symbol table info available. +#3 0x00003fffb17e4d34 in __assert_fail () from /lib64/libc.so.6 +No symbol table info available. +#4 0x00000000100631fc in handle_copied (bs=0x42ba9ad0, guest_offset=4210688, host_offset=0x3fffaf4bfab0, bytes=0x3fffaf4bfab8, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1108 + s = 0x42bb5d80 + l2_index = 0 + cluster_offset = 4210688 + l2_table = 0x0 + nb_clusters = 1119575424 + keep_clusters = 0 + ret = 0 + __PRETTY_FUNCTION__ = "handle_copied" +#5 0x0000000010064118 in qcow2_alloc_cluster_offset (bs=0x42ba9ad0, offset=4194304, bytes=0x3fffaf4bfb4c, host_offset=0x3fffaf4bfb58, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1498 + s = 0x42bb5d80 + start = 4210688 + remaining = 2686976 + cluster_offset = 4294983168 + cur_bytes = 2686976 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +#6 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x42ba9ad0, offset=4194304, bytes=2703360, qiov=0x3fffc7cc9ee0, flags=0) at block/qcow2.c:1919 + s = 0x42bb5d80 + offset_in_cluster = 0 + ret = 0 + cur_bytes = 2703360 + cluster_offset = 4294950912 + hd_qiov = {iov = 0x42b74fb0, niov = 1, nalloc = 1, size = 16384} + bytes_done = 88576 + cluster_data = 0x0 + l2meta = 0x42bb5d20 + __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +#7 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x42ba9ad0, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=16) at block/io.c:898 + drv = 0x102036f0 <bdrv_qcow2> + sector_num = 1119538320 + nb_sectors = 2841469356 + ret = 2116577536 + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#8 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x42bb8250, req=0x3fffaf4bfdd8, offset=4105728, bytes=2791936, align=1, qiov=0x3fffc7cc9ee0, flags=16) + at block/io.c:1440 + bs = 0x42ba9ad0 + drv = 0x102036f0 <bdrv_qcow2> + waited = false + ret = 0 +---Type <return> to continue, or q <return> to quit--- + end_sector = 13472 + bytes_remaining = 2791936 + max_transfer = 2147483647 + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#9 0x00000000100ac4ac in bdrv_co_pwritev (child=0x42bb8250, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/io.c:1691 + bs = 0x42ba9ad0 + req = {bs = 0x42ba9ad0, offset = 4105728, bytes = 2791936, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 4105728, + overlap_bytes = 2791936, list = {le_next = 0x0, le_prev = 0x42bacd48}, co = 0x42bb50b0, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fffaf4bfe20}}, waiting_for = 0x0} + align = 1 + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x3fffaf4bfdb0, niov = -1353974288, nalloc = 16383, size = 4105728} + use_local_qiov = false + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#10 0x000000001008da0c in blk_co_pwritev (blk=0x42b99410, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 + ret = 0 + bs = 0x42ba9ad0 +#11 0x000000001008db68 in blk_write_entry (opaque=0x3fffc7cc9ef8) at block/block-backend.c:1110 + rwco = 0x3fffc7cc9ef8 +#12 0x00000000101aa444 in coroutine_trampoline (i0=1119572144, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x42bb50b0, i = {1119572144, 0}} + self = 0x42bb50b0 + co = 0x42bb50b0 +#13 0x00003fffb1802b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#14 0x0000000000000000 in ?? () +No symbol table info available. + +will attach images_fuzzer image. + + + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=93bbaf03ff7fd490e82 + diff --git a/results/classifier/zero-shot/108/none/1736376 b/results/classifier/zero-shot/108/none/1736376 new file mode 100644 index 000000000..66e288644 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1736376 @@ -0,0 +1,31 @@ +device: 0.522 +graphic: 0.481 +semantic: 0.478 +network: 0.462 +files: 0.416 +vnc: 0.368 +other: 0.334 +socket: 0.326 +performance: 0.263 +PID: 0.255 +boot: 0.240 +permissions: 0.211 +debug: 0.172 +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/zero-shot/108/none/1737444 b/results/classifier/zero-shot/108/none/1737444 new file mode 100644 index 000000000..af5e16e0f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1737444 @@ -0,0 +1,148 @@ +other: 0.410 +performance: 0.407 +graphic: 0.361 +device: 0.340 +debug: 0.332 +permissions: 0.325 +semantic: 0.318 +PID: 0.281 +vnc: 0.269 +network: 0.246 +socket: 0.240 +boot: 0.227 +files: 0.219 +KVM: 0.096 + +gccgo setcontext conftest crashes qemu-sh4 + +While testing gccgo on sh4 to add SH platform definitions to libgo, I discovered that the following conftest program which is part of the libgo configure script crashes on qemu-sh4: + +(sid-sh4-sbuild)root@z6:/# cat setcontext.c +#include <pthread.h> +#include <stdlib.h> +#include <ucontext.h> +#include <unistd.h> + +__thread int tls; + +static char stack[10 * 1024 * 1024]; +static ucontext_t c; + +/* Called via makecontext/setcontext. */ + +static void +cfn (void) +{ + exit (tls); +} + +/* Called via pthread_create. */ + +static void * +tfn (void *dummy) +{ + /* The thread should still see this value after calling + setcontext. */ + tls = 0; + + setcontext (&c); + + /* The call to setcontext should not return. */ + abort (); +} + +int +main () +{ + pthread_t tid; + + /* The thread should not see this value. */ + tls = 1; + + if (getcontext (&c) < 0) + abort (); + + c.uc_stack.ss_sp = stack; +#ifdef MAKECONTEXT_STACK_TOP + c.uc_stack.ss_sp += sizeof stack; +#endif + c.uc_stack.ss_flags = 0; + c.uc_stack.ss_size = sizeof stack; + c.uc_link = NULL; + makecontext (&c, cfn, 0); + + if (pthread_create (&tid, NULL, tfn, NULL) != 0) + abort (); + + if (pthread_join (tid, NULL) != 0) + abort (); + + /* The thread should have called exit. */ + abort (); +} + +(sid-sh4-sbuild)root@z6:/# gcc -o setcontext -lpthread setcontext.c +(sid-sh4-sbuild)root@z6:/# ./setcontext +Unhandled trap: 0x180 +pc=0x7f69235e sr=0x00000000 pr=0x00400710 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0x7f658478 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x7f692320 fpul=0x00000000 +r0=0x00e11158 r1=0x00000000 r2=0x00000001 r3=0x7ffff2e0 +r4=0x00e11068 r5=0x7ffff314 r6=0x7ffff31c r7=0x00000000 +r8=0x004007b0 r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0x7f79ac54 r13=0x00000000 r14=0x7ffff288 r15=0x7ffff288 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@z6:/# + +The same code works fine on my Renesas SH7785LCR evaluation board: + +root@tirpitz:~> uname -a +Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a GNU/Linux +root@tirpitz:~> gcc -o setcontext setcontext.c -lpthread +root@tirpitz:~> ./setcontext +root@tirpitz:~> echo $? +0 +root@tirpitz:~> + +Due to this bug, it is not possible to compile gcc-7 with the Go frontend enabled on qemu-sh4. + +This still reproduces on git master: + +(sid-sh4-sbuild)root@nofan:/# gcc setcontext.c -o setcontext -lpthread +(sid-sh4-sbuild)root@nofan:/# ./setcontext +Unhandled trap: 0x180 +pc=0x7f68e99e sr=0x00000000 pr=0x00400750 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0x7f7a2de8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x7f68e960 fpul=0x00000000 +r0=0x00e11158 r1=0x00000000 r2=0x00000001 r3=0x7ffff590 +r4=0x00e11068 r5=0x7ffff5c4 r6=0x7ffff5cc r7=0x00000000 +r8=0x004007f0 r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0x7f79ec64 r13=0x00000000 r14=0x7ffff538 r15=0x7ffff538 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@nofan:/# + +And it is fixed by reverting 61dedf2af7 + +(sid-sh4-sbuild)root@nofan:/# ./setcontext +(sid-sh4-sbuild)root@nofan:/# echo $? +0 +(sid-sh4-sbuild)root@nofan:/# + +So it's presumably the same bug as https://bugs.launchpad.net/qemu/+bug/1796520 + +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/zero-shot/108/none/1738507 b/results/classifier/zero-shot/108/none/1738507 new file mode 100644 index 000000000..448356534 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1738507 @@ -0,0 +1,35 @@ +other: 0.563 +boot: 0.560 +graphic: 0.547 +semantic: 0.497 +performance: 0.487 +device: 0.420 +debug: 0.349 +permissions: 0.310 +network: 0.305 +vnc: 0.270 +PID: 0.268 +files: 0.263 +socket: 0.218 +KVM: 0.091 + +qemu sometimes stuck when booting windows 10 + +I am using qemu-2.10.1, or actually libvirt, to create a virtual machine, running microsoft windows 10 pro operating system. +It installed fine and was actually working, however sometimes when trying to boot the vm, the whole boot process gets stuck. +For some reason, it seemed to happen only when enough physical memory is taken so that, when booting a windows vm that has 4gb of available ram, host starts swapping some other processes. It is not always happening there, but often it happens, and I do not remember seeing any case of this happening when not swapping, maybe a kind of a timing issue? +When this happens, I usually try to hard reset the machine by libvirt reset command or equivalent system_reset on qemu monitor, however the whole reset does not happen, and the command is a noop. That makes me think it is a qemu bug, not windows refusing operation. At the time of this event, qemu monitor and spice server are working correctly, are not stuck, and even doing things like system reset does not result in a monitor hang. It is also possible to quit qemu normally. +I tried to workaround the bug by guessing what may cause it. Switched from bios to uefi, changed virtio-scsi to ahci temporarily, and disabled virtio-balloon in case it would be buggy, with no visible change. +I will attach a libvirt log, because it contains qemu command line. I will also attach an example qemu backtrace. +From what i know, both vcpu threads are working normally, at least none of them is stuck in a vcpu, nor deadlocked, etc. So backtrace could be different each time I tried to get it. + + + + + +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/zero-shot/108/none/1739304 b/results/classifier/zero-shot/108/none/1739304 new file mode 100644 index 000000000..efb3b63fc --- /dev/null +++ b/results/classifier/zero-shot/108/none/1739304 @@ -0,0 +1,186 @@ +other: 0.507 +files: 0.477 +graphic: 0.476 +debug: 0.472 +device: 0.464 +semantic: 0.461 +permissions: 0.456 +socket: 0.451 +PID: 0.449 +performance: 0.448 +network: 0.445 +KVM: 0.439 +boot: 0.431 +vnc: 0.427 + +Passing a directory to (eg.) -cdrom results in misleading error message + +For example: + + qemu-system-x86_64 -cdrom /path/to/directory + +Results in: + + Could not read image for determining its format: File too large + +Yep, can repeat it here, it seems pretty random which error it gives: + +[dgilbert@dgilbert-t530 try]$ ./x86_64-softmmu/qemu-system-x86_64 -cdrom /tmp +qemu-system-x86_64: -cdrom /tmp: Could not refresh total sector count: Invalid argument +[dgilbert@dgilbert-t530 try]$ ./x86_64-softmmu/qemu-system-x86_64 -cdrom /var +qemu-system-x86_64: -cdrom /var: Could not read image for determining its format: File too large + + + + +On 12/20/2017 05:31 AM, Dr. David Alan Gilbert wrote: +> Yep, can repeat it here, it seems pretty random which error it gives: +> +> [dgilbert@dgilbert-t530 try]$ ./x86_64-softmmu/qemu-system-x86_64 -cdrom /tmp +> qemu-system-x86_64: -cdrom /tmp: Could not refresh total sector count: Invalid argument +> [dgilbert@dgilbert-t530 try]$ ./x86_64-softmmu/qemu-system-x86_64 -cdrom /var +> qemu-system-x86_64: -cdrom /var: Could not read image for determining its format: File too large +> +> +> ** Changed in: qemu +> Status: New => Confirmed +> + +Looks like directories play funny games. + +Probably seems to be ultimately that bs->total_sectors gets set to a +very silly and large value, which later on will fail the format probing +because bdrv_getlength refuses to play nice with such a stupidly large +value: + + ret = ret > INT64_MAX / BDRV_SECTOR_SIZE ? -EFBIG : ret; + return ret < 0 ? ret : ret * BDRV_SECTOR_SIZE; + +but the real villain is down here, when we add the "file" to to a raw +posix file bs for the hopes of probing it. + +#0 0x0000555555be7e2e in raw_getlength (bs=0x555556b23bb0) at +/home/bos/jhuston/src/qemu/block/file-posix.c:1964 +#1 0x0000555555b81630 in refresh_total_sectors (bs=0x555556b23bb0, +hint=0) at /home/bos/jhuston/src/qemu/block.c:733 +#2 0x0000555555b82490 in bdrv_open_driver (bs=0x555556b23bb0, +drv=0x555556541420 <bdrv_file>, node_name=0x0, options=0x555556b28090, +open_flags=16384, errp=0x7fffffffda80) at +/home/bos/jhuston/src/qemu/block.c:1162 +#3 0x0000555555b82d67 in bdrv_open_common (bs=0x555556b23bb0, file=0x0, +options=0x555556b28090, errp=0x7fffffffda80) + at /home/bos/jhuston/src/qemu/block.c:1404 +#4 0x0000555555b8578f in bdrv_open_inherit (filename=0x555556b143a0 +"/media/ext/", reference=0x0, options=0x555556b28090, flags=32768, +parent=0x555556b1d6b0, child_role=0x5555563b04a0 <child_file>, +errp=0x7fffffffdbe0) at /home/bos/jhuston/src/qemu/block.c:2628 +#5 0x0000555555b84d10 in bdrv_open_child_bs (filename=0x555556b143a0 +"/media/ext/", options=0x555556b21a60, bdref_key=0x555555e55712 "file", +parent=0x555556b1d6b0, child_role=0x5555563b04a0 <child_file>, +allow_none=true, errp=0x7fffffffdbe0) at +/home/bos/jhuston/src/qemu/block.c:2324 +#6 0x0000555555b85594 in bdrv_open_inherit (filename=0x555556b143a0 +"/media/ext/", reference=0x0, options=0x555556b21a60, flags=0, +parent=0x0, child_role=0x0, errp=0x7fffffffdef0) at +/home/bos/jhuston/src/qemu/block.c:2576 +#7 0x0000555555b85b10 in bdrv_open (filename=0x555556b143a0 +"/media/ext/", reference=0x0, options=0x555556b1b280, flags=0, +errp=0x7fffffffdef0) + at /home/bos/jhuston/src/qemu/block.c:2710 +#8 0x0000555555bdd428 in blk_new_open (filename=0x555556b143a0 +"/media/ext/", reference=0x0, options=0x555556b1b280, flags=0, +errp=0x7fffffffdef0) at /home/bos/jhuston/src/qemu/block/block-backend.c:323 +#9 0x0000555555911a60 in blockdev_init (file=0x555556b143a0 +"/media/ext/", bs_opts=0x555556b1b280, errp=0x7fffffffdef0) + at /home/bos/jhuston/src/qemu/blockdev.c:587 + + +specifically: + +(gdb) s +1963 size = lseek(s->fd, 0, SEEK_END); +(gdb) s +1964 if (size < 0) { +(gdb) print size +$37 = 9223372036854775807 + +cool, cool, cool. This value is 0x7fffffffffffffff and errno isn't set. +cool and good function. + +so, lseek on a folder returns crazy nonsense. Perhaps we ought to +actually specifically disallow folders, we don't appear to. + +Learned something today. + +--js + + + + +On 01/31/2018 01:36 PM, Michal Suchánek wrote: +> On Wed, 20 Dec 2017 21:57:00 -0500 +> John Snow <email address hidden> wrote: +> +>> On 12/20/2017 05:31 AM, Dr. David Alan Gilbert wrote: +>>> Yep, can repeat it here, it seems pretty random which error it +>>> gives: +>>> +>>> [dgilbert@dgilbert-t530 try]$ ./x86_64-softmmu/qemu-system-x86_64 +>>> -cdrom /tmp qemu-system-x86_64: -cdrom /tmp: Could not refresh +>>> total sector count: Invalid argument [dgilbert@dgilbert-t530 +>>> try]$ ./x86_64-softmmu/qemu-system-x86_64 -cdrom /var +>>> qemu-system-x86_64: -cdrom /var: Could not read image for +>>> determining its format: File too large +>>> +>>> +>>> ** Changed in: qemu +>>> Status: New => Confirmed +>>> +>> +>> Looks like directories play funny games. +>> +> +> ... +> +>> specifically: +>> +>> (gdb) s +>> 1963 size = lseek(s->fd, 0, SEEK_END); +>> (gdb) s +>> 1964 if (size < 0) { +>> (gdb) print size +>> $37 = 9223372036854775807 +>> +>> cool, cool, cool. This value is 0x7fffffffffffffff and errno isn't +>> set. cool and good function. +> +> Indeed: The behavior of lseek() on devices which are incapable of +> seeking is implementation-defined. +> +>> +>> so, lseek on a folder returns crazy nonsense. Perhaps we ought to +>> actually specifically disallow folders, we don't appear to. +> +> It probably returns -1 which it is supposed to do on error. It should +> also set errno in that case, though. +> +> So this is probably bug in the error handling code in lseek. +> +> Thanks +> +> Michal +> + +Thanks. It looks like we can't make stronger guarantees about the +behavior of lseek, so I submitted a patch to ratchet down QEMU's +acceptable file types: + +https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg05055.html + +Thanks, +--John + + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=230ff73904e72dde2d7718c2 + diff --git a/results/classifier/zero-shot/108/none/1750 b/results/classifier/zero-shot/108/none/1750 new file mode 100644 index 000000000..1a09750f4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1750 @@ -0,0 +1,16 @@ +performance: 0.498 +graphic: 0.416 +semantic: 0.261 +device: 0.243 +files: 0.155 +vnc: 0.113 +other: 0.109 +boot: 0.063 +network: 0.051 +socket: 0.048 +debug: 0.047 +PID: 0.046 +permissions: 0.030 +KVM: 0.021 + +target/ppc/translate.c - ppc_fixup_cpu and VSX - is still necessary? diff --git a/results/classifier/zero-shot/108/none/1751422 b/results/classifier/zero-shot/108/none/1751422 new file mode 100644 index 000000000..ef4e8396e --- /dev/null +++ b/results/classifier/zero-shot/108/none/1751422 @@ -0,0 +1,73 @@ +semantic: 0.524 +graphic: 0.506 +socket: 0.497 +other: 0.473 +device: 0.451 +files: 0.441 +vnc: 0.425 +debug: 0.419 +PID: 0.400 +network: 0.386 +permissions: 0.383 +performance: 0.360 +boot: 0.348 +KVM: 0.292 + +some instructions translate error in x86 + +There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. + +Could you please provide some more information about the problem? What's exactly the error? If you've already got a patch, please have a look at https://wiki.qemu.org/Contribute/SubmitAPatch to get some information how to submit it. + +The patch is In this mail attachments, which is patch for version 2.11.1 target/i386/translate.c. +The patch is created by diff. +my English is so poor to explain how the error come, but you can see the patch result to get it. + + + + + + + + +At 2018-02-25 17:41:15, "Thomas Huth" <email address hidden> wrote: +>Could you please provide some more information about the problem? What's +>exactly the error? If you've already got a patch, please have a look at +>https://wiki.qemu.org/Contribute/SubmitAPatch to get some information +>how to submit it. +> +>** Changed in: qemu +> Status: New => Incomplete +> +>-- +>You received this bug notification because you are subscribed to the bug +>report. +>https://bugs.launchpad.net/bugs/1751422 +> +>Title: +> some instructions translate error in x86 +> +>Status in QEMU: +> Incomplete +> +>Bug description: +> There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +> The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. +> +>To manage notifications about this bug go to: +>https://bugs.launchpad.net/qemu/+bug/1751422/+subscriptions + + +[Expired for QEMU because there has been no activity for 60 days.] + +We shouldn't really have let this expire, the submitter has a patch attached to the bug. + +Yabi: do you have a simple test program which fails without this patch and works with it? If so can you attach it to the bug ? + + +I believe this to be fixed by cfcca361d77, which is present in 2.12 but not 2.11. + +Since Richard pointed out a commit which fixed this in 2.12 and we haven't heard back from the submitter, I'm going to close this bug as fixed. + + diff --git a/results/classifier/zero-shot/108/none/1753437 b/results/classifier/zero-shot/108/none/1753437 new file mode 100644 index 000000000..6e7da269e --- /dev/null +++ b/results/classifier/zero-shot/108/none/1753437 @@ -0,0 +1,63 @@ +device: 0.438 +semantic: 0.409 +socket: 0.362 +PID: 0.303 +vnc: 0.279 +other: 0.271 +network: 0.249 +files: 0.223 +graphic: 0.217 +performance: 0.203 +boot: 0.176 +KVM: 0.102 +permissions: 0.102 +debug: 0.098 + +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/zero-shot/108/none/1754542 b/results/classifier/zero-shot/108/none/1754542 new file mode 100644 index 000000000..09e96ec32 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1754542 @@ -0,0 +1,2020 @@ +other: 0.552 +permissions: 0.551 +device: 0.482 +files: 0.475 +KVM: 0.468 +vnc: 0.464 +graphic: 0.446 +performance: 0.440 +semantic: 0.439 +debug: 0.417 +boot: 0.399 +PID: 0.387 +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/zero-shot/108/none/1756519 b/results/classifier/zero-shot/108/none/1756519 new file mode 100644 index 000000000..78f169dca --- /dev/null +++ b/results/classifier/zero-shot/108/none/1756519 @@ -0,0 +1,73 @@ +other: 0.397 +KVM: 0.318 +vnc: 0.313 +device: 0.258 +debug: 0.239 +performance: 0.228 +graphic: 0.228 +permissions: 0.222 +files: 0.203 +semantic: 0.193 +PID: 0.186 +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/zero-shot/108/none/1777786 b/results/classifier/zero-shot/108/none/1777786 new file mode 100644 index 000000000..ea8e1a34b --- /dev/null +++ b/results/classifier/zero-shot/108/none/1777786 @@ -0,0 +1,70 @@ +device: 0.477 +graphic: 0.474 +PID: 0.473 +performance: 0.423 +permissions: 0.423 +files: 0.395 +boot: 0.362 +other: 0.339 +semantic: 0.322 +KVM: 0.314 +network: 0.290 +vnc: 0.233 +socket: 0.231 +debug: 0.228 + +virtio-gpu-3d.c: change virtio_gpu_fence_poll timer scale + +We use virtio-gpu to accelerate Unigine Heaven Benchmark in VM. But we get only 5 FPS when we use AMD RX460 in our host. +We found that guest os spent a lot of time in waiting for the return of glMapBufferRange/glUnmapBuffer commad. We suspected the host GPU was waiting for fence. So we finally change the timer of fence_poll. Afer change timer from + ms to us， Benchmark result raise up to 22 FPS. + +From a4003af5c4fe92d55353f42767d0c45de95bb78f Mon Sep 17 00:00:00 2001 +From: chen wei <email address hidden> +Date: Fri, 8 Jun 2018 17:34:45 +0800 +Subject: [PATCH] virtio-gpu:improve 3d performance greatly + + opengl function need fence support.when CPU execute opengl function, it need wait fence for synchronize GPU. +so qemu must deal with fence timely as possible. but now the expire time of the timer to deal with fence is 10 ms. +I think it is too long for opengl. So i will change it to 20 ns. + Before change, when i play Unigine_Heaven 3d game with virglrenderer, the fps is 3. atfer change the fps up to 23. + +Signed-off-by: chen wei <email address hidden> +Signed-off-by: wang qiang <email address hidden> +--- + hw/display/virtio-gpu-3d.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c +index 3558f38..c0a5d21 100644 +--- a/hw/display/virtio-gpu-3d.c ++++ b/hw/display/virtio-gpu-3d.c +@@ -582,7 +582,7 @@ static void virtio_gpu_fence_poll(void *opaque) + virgl_renderer_poll(); + virtio_gpu_process_cmdq(g); + if (!QTAILQ_EMPTY(&g->cmdq) || !QTAILQ_EMPTY(&g->fenceq)) { +- timer_mod(g->fence_poll, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 10); ++ timer_mod(g->fence_poll, qemu_clock_get_us(QEMU_CLOCK_VIRTUAL) + 20); + } + } + +@@ -629,7 +629,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g) + return ret; + } + +- g->fence_poll = timer_new_ms(QEMU_CLOCK_VIRTUAL, ++ g->fence_poll = timer_new_us(QEMU_CLOCK_VIRTUAL, + virtio_gpu_fence_poll, g); + + if (virtio_gpu_stats_enabled(g->conf)) { +-- +2.7.4 + + + +Please don't use the bug tracker for providing patches, and send it to the mailing list instead, see: https://wiki.qemu.org/Contribute/SubmitAPatch + +Did you ever send your patch to the mailing list for discussion? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1779955 b/results/classifier/zero-shot/108/none/1779955 new file mode 100644 index 000000000..aca1ab4f0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1779955 @@ -0,0 +1,107 @@ +graphic: 0.311 +other: 0.270 +semantic: 0.239 +debug: 0.210 +PID: 0.192 +vnc: 0.178 +device: 0.155 +permissions: 0.151 +KVM: 0.142 +socket: 0.126 +network: 0.113 +boot: 0.104 +performance: 0.099 +files: 0.079 + +qemu linux-user requires read permissions on memory passed to syscalls that should only need write access + +When read() function takes an mmap'ed address as output buffer, it returns EFAULT. The expected behavior is it should just work. + +The following code works for qemu-system-arm, but not for qemu-arm-static. + + + +Steps to reproduce (please substitute /path/to/qemu-arm-static with the path of the binary, and /tmp/a.cpp with the example source code attached): + +# First register binfmt_misc +[hidden]$ docker run --rm --privileged multiarch/qemu-user-static:register --reset + +# Compile the code and run +[hidden]$ docker run --rm -it -v /tmp/a.cpp:/tmp/a.cpp -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static arm32v7/ubuntu:18.04 bash -c '{ apt update -y && apt install -y g++; } >& /dev/null && g++ -std=c++14 /tmp/a.cpp -o /tmp/a.out && echo hehe > /tmp/haha.txt && /tmp/a.out' +ofd=3 +ftruncate=0 +mmap=0xff3f5000 +fd=4 +0xff3f5023 -1 14 + + + +The expected result in qemu-system-arm as well as natively on x86_64 host: +hidden$ ./a.out +ofd=3 +ftruncate=0 +mmap=0xb6fb7000 +fd=4 +0xb6fb7023 5 0 + + + +The problem here is not the mmap(), it is that you are mapping it as only PROT_WRITE and not also PROT_READ. With the native kernel, syscalls which only write to a buffer and do not read from it (like read(2)) only require write permissions on that memory. QEMU's implementation requires both write and read permission. + +This is a QEMU bug, but not a major one, because in practice no guest binaries set up memory that is only writable and can't be read (what would they do with the data that they wrote into that memory?). You can work around it in your test program by using mmap(..., PROT_READ | PROT_WRITE, ...), which will allow it to work in QEMU. + +(Technical QEMU internal notes for other developers: the issue here is that we do permissions checks in syscall.c using lock_user(VERIFY_WRITE, ...) etc, but in access_ok() we treat VERIFY_WRITE as "implies read access" when we're choosing the permissions flags to pass to page_check_range(). To fix this we would have to check all the places we use VERIFY_WRITE to identify which should be "only need write" and which are "need both read and write".) + + +Thanks Peter for your information. + +I was hit by the bug when trying to compile bazel (a build system open-sourced by Google: https://bazel.build) and the code is at https://github.com/bazelbuild/bazel/blob/master/third_party/ijar/mapped_file_unix.cc#L116 + +Of course I can send PR to fix that in bazel source, but I would say it is not true that "in practice no guest binaries set up memory that is only writable and can't be read". It is legitimate requirement and coding practice. + +Oh, yes, I see -- it's mmapping the file specifically in order to write the data to the file system. Yes, I agree that's a reasonable thing to do. + + +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.] + +Still a bug. + + + +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/470 + + diff --git a/results/classifier/zero-shot/108/none/1788098 b/results/classifier/zero-shot/108/none/1788098 new file mode 100644 index 000000000..9a393307f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1788098 @@ -0,0 +1,1008 @@ +permissions: 0.582 +performance: 0.544 +device: 0.512 +network: 0.502 +boot: 0.495 +semantic: 0.486 +KVM: 0.431 +PID: 0.415 +other: 0.411 +debug: 0.401 +graphic: 0.380 +socket: 0.344 +vnc: 0.344 +files: 0.326 + +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/zero-shot/108/none/1791763 b/results/classifier/zero-shot/108/none/1791763 new file mode 100644 index 000000000..4ce3f4389 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1791763 @@ -0,0 +1,44 @@ +device: 0.505 +debug: 0.427 +semantic: 0.389 +performance: 0.379 +network: 0.367 +vnc: 0.328 +graphic: 0.294 +other: 0.285 +socket: 0.283 +files: 0.247 +PID: 0.236 +permissions: 0.208 +boot: 0.195 +KVM: 0.089 + +broken signal handling in nios2 user-mode emulation + +This bug is against the 3.0 release. + +It appears that the signal handling parts of the nios2 user-mode emulation have never really been completed or tested. Some examples of failing tests from the GCC testsuite are gcc.dg/pr78185.c and gcc.dg/cleanup-10.c. + +Some problems I've identified and tried to fix with the attached patch are: + +- Code copied from the Linux kernel wasn't adjusted to differentiate between host and target data types and address spaces. + +- The sigaltstack() system call returns EINVAL because fields are listed in the wrong order in struct target_sigaltstack. + +With this patch, the system calls to set up the signal handler are returning successfully, but the handler isn't being invoked, so something is still wrong. I think I need another pair of eyes to look over this code. + + + +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. + +A quick eyeball of the patch and the current QEMU tree indicates that at least some of the bugs it's trying to fix still exist (notably a lot of use of "long" in various target_* structures, which should not be using types with a width dependent on the host system.) + + +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/261 + + diff --git a/results/classifier/zero-shot/108/none/1791796 b/results/classifier/zero-shot/108/none/1791796 new file mode 100644 index 000000000..68aa1dba5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1791796 @@ -0,0 +1,1140 @@ +other: 0.600 +debug: 0.554 +KVM: 0.548 +permissions: 0.536 +semantic: 0.535 +device: 0.531 +PID: 0.527 +graphic: 0.524 +network: 0.517 +performance: 0.517 +vnc: 0.510 +socket: 0.481 +files: 0.476 +boot: 0.466 + +unimplemented thread syscalls in nios2 user-mode emulation + +This bug is reported against the 3.0 release. + +I noticed that the GCC test gcc.dg/torture/tls/tls-test.c is failing when run in user-mode qemu for nios2 target. The problem appears to be that the thread-related syscalls are unimplemented in qemu. Here is output from running with -strace: + +22484 brk(NULL) = 0x00005000 +22484 uname(0x7fffef5a) = 0 +22484 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,0x5) = -1 errno=2 (No such file or directory) +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +22484 fstatat64(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls",0x7fffe870,0) = -1 errno=2 (No such file or directory) +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +22484 read(3,0x7fffe954,512) = 512 +22484 fstat64(3,0x7fffe870) = 0 +22484 mmap2(NULL,803596,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f716000 +22484 mmap2(0x7f7d8000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xc1) = 0x7f7d8000 +22484 close(3) = 0 +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +22484 read(3,0x7fffe948,512) = 512 +22484 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x7f714000 +22484 fstat64(3,0x7fffe864) = 0 +22484 mmap2(NULL,120700,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f6f6000 +22484 mprotect(0x7f70e000,4096,PROT_NONE) = 0 +22484 mmap2(0x7f70f000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x18) = 0x7f70f000 +22484 mmap2(0x7f712000,6012,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f712000 +22484 close(3) = 0 +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +22484 read(3,0x7fffe93c,512) = 512 +22484 fstat64(3,0x7fffe858) = 0 +22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +22484 close(3) = 0 +22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +22484 mprotect(0x00003000,4096,PROT_READ) = 0 +22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +22484 brk(NULL) = 0x00005000 +22484 brk(0x00026000) = 0x00026000 +22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +22484 exit(0) + = 0 +22484 fstat64(1,0x7fffef48) = 0 +22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 + = 42 +22484 exit_group(1) +sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +22484 close(3) = 0 +22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +22484 mprotect(0x00003000,4096,PROT_READ) = 0 +22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +22484 brk(NULL) = 0x00005000 +22484 brk(0x00026000) = 0x00026000 +22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +22484 exit(0) + = 0 +22484 fstat64(1,0x7fffef48) = 0 +22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 + = 42 +22484 exit_group(1) +sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +22484 close(3) = 0 +22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +22484 mprotect(0x00003000,4096,PROT_READ) = 0 +22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +22484 brk(NULL) = 0x00005000 +22484 brk(0x00026000) = 0x00026000 +22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +22484 exit(0) + = 0 +22484 fstat64(1,0x7fffef48) = 0 +22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 + = 42 +22484 exit_group(1) + +Note that set_robust_list and clone are reported as unimplemented. + +I've reported the problems with the signal syscalls separately here. +https://bugs.launchpad.net/qemu/+bug/1791763 + + +Sandra Loosemore <email address hidden> writes: + +> Public bug reported: +> +> This bug is reported against the 3.0 release. +> +> I noticed that the GCC test gcc.dg/torture/tls/tls-test.c is failing +> when run in user-mode qemu for nios2 target. The problem appears to be +> that the thread-related syscalls are unimplemented in qemu. Here is +> output from running with -strace: + +One thing that would help in better supporting NIOS is if we could add +support for building linux-user tests for it in test/tcg. For this we +need a distribution that ships a decent cross compiler or create a +docker recipe that packages it up so we can build and run the tests. + +Are you just building GCC straight from source or can you point to a +recommended location for a decent packaged gcc? + +> +> 22484 brk(NULL) = 0x00005000 +> 22484 uname(0x7fffef5a) = 0 +> 22484 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,0x5) = -1 errno=2 (No such file or directory) +> 22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +> 22484 fstatat64(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls",0x7fffe870,0) = -1 errno=2 (No such file or directory) +> 22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +> 22484 read(3,0x7fffe954,512) = 512 +> 22484 fstat64(3,0x7fffe870) = 0 +> 22484 mmap2(NULL,803596,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f716000 +> 22484 mmap2(0x7f7d8000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xc1) = 0x7f7d8000 +> 22484 close(3) = 0 +> 22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +> 22484 read(3,0x7fffe948,512) = 512 +> 22484 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x7f714000 +> 22484 fstat64(3,0x7fffe864) = 0 +> 22484 mmap2(NULL,120700,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f6f6000 +> 22484 mprotect(0x7f70e000,4096,PROT_NONE) = 0 +> 22484 mmap2(0x7f70f000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x18) = 0x7f70f000 +> 22484 mmap2(0x7f712000,6012,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f712000 +> 22484 close(3) = 0 +> 22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +> 22484 read(3,0x7fffe93c,512) = 512 +> 22484 fstat64(3,0x7fffe858) = 0 +> 22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +> 22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +> 22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +> 22484 close(3) = 0 +> 22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +> 22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +> 22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +> 22484 mprotect(0x00003000,4096,PROT_READ) = 0 +> 22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +> 22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +> 22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +> 22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +> 22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +> 22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +> 22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +> 22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +> 22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +> 22484 brk(NULL) = 0x00005000 +> 22484 brk(0x00026000) = 0x00026000 +> 22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +> 22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +> 22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +> 22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +> 22484 exit(0) +> = 0 +> 22484 fstat64(1,0x7fffef48) = 0 +> 22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 +> = 42 +> 22484 exit_group(1) +> sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +> 22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +> 22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +> 22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +> 22484 close(3) = 0 +> 22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +> 22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +> 22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +> 22484 mprotect(0x00003000,4096,PROT_READ) = 0 +> 22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +> 22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +> 22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +> 22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +> 22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +> 22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +> 22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +> 22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +> 22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +> 22484 brk(NULL) = 0x00005000 +> 22484 brk(0x00026000) = 0x00026000 +> 22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +> 22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +> 22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +> 22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +> 22484 exit(0) +> = 0 +> 22484 fstat64(1,0x7fffef48) = 0 +> 22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 +> = 42 +> 22484 exit_group(1) +> sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +> 22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +> 22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +> 22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +> 22484 close(3) = 0 +> 22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +> 22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +> 22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +> 22484 mprotect(0x00003000,4096,PROT_READ) = 0 +> 22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +> 22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +> 22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +> 22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +> 22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +> 22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +> 22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +> 22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +> 22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +> 22484 brk(NULL) = 0x00005000 +> 22484 brk(0x00026000) = 0x00026000 +> 22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +> 22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +> 22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +> 22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +> 22484 exit(0) +> = 0 +> 22484 fstat64(1,0x7fffef48) = 0 +> 22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 +> = 42 +> 22484 exit_group(1) +> +> Note that set_robust_list and clone are reported as unimplemented. +> +> I've reported the problems with the signal syscalls separately here. +> https://bugs.launchpad.net/qemu/+bug/1791763 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New + + +-- +Alex Bennée + + + +Thomas Huth <email address hidden> writes: + +> On 2018-09-11 10:49, Alex Bennée wrote: +>> +>> Sandra Loosemore <email address hidden> writes: +>> +>>> Public bug reported: +>>> +>>> This bug is reported against the 3.0 release. +>>> +>>> I noticed that the GCC test gcc.dg/torture/tls/tls-test.c is failing +>>> when run in user-mode qemu for nios2 target. The problem appears to be +>>> that the thread-related syscalls are unimplemented in qemu. Here is +>>> output from running with -strace: +>> +>> One thing that would help in better supporting NIOS is if we could add +>> support for building linux-user tests for it in test/tcg. For this we +>> need a distribution that ships a decent cross compiler or create a +>> docker recipe that packages it up so we can build and run the tests. +>> +>> Are you just building GCC straight from source or can you point to a +>> recommended location for a decent packaged gcc? +> +> Not sure if it's of any help, but buildroot.org has support for nios2, +> including automatic setup of a cross-compiler... + +Maybe its time to add a buildroot base docker image with rules for +building the various additional toolchains. I'll have a go. + +> +> Thomas +> +> +>>> 22484 brk(NULL) = 0x00005000 +>>> 22484 uname(0x7fffef5a) = 0 +>>> 22484 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,0x5) = -1 errno=2 (No such file or directory) +>>> 22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +>>> 22484 fstatat64(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls",0x7fffe870,0) = -1 errno=2 (No such file or directory) +>>> 22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +>>> 22484 read(3,0x7fffe954,512) = 512 +>>> 22484 fstat64(3,0x7fffe870) = 0 +>>> 22484 mmap2(NULL,803596,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f716000 +>>> 22484 mmap2(0x7f7d8000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xc1) = 0x7f7d8000 +>>> 22484 close(3) = 0 +>>> 22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +>>> 22484 read(3,0x7fffe948,512) = 512 +>>> 22484 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x7f714000 +>>> 22484 fstat64(3,0x7fffe864) = 0 +>>> 22484 mmap2(NULL,120700,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f6f6000 +>>> 22484 mprotect(0x7f70e000,4096,PROT_NONE) = 0 +>>> 22484 mmap2(0x7f70f000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x18) = 0x7f70f000 +>>> 22484 mmap2(0x7f712000,6012,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f712000 +>>> 22484 close(3) = 0 +>>> 22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +>>> 22484 read(3,0x7fffe93c,512) = 512 +>>> 22484 fstat64(3,0x7fffe858) = 0 +>>> 22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +>>> 22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +>>> 22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +>>> 22484 close(3) = 0 +>>> 22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +>>> 22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +>>> 22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +>>> 22484 mprotect(0x00003000,4096,PROT_READ) = 0 +>>> 22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +>>> 22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +>>> 22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +>>> 22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +>>> 22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +>>> 22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +>>> 22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +>>> 22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +>>> 22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +>>> 22484 brk(NULL) = 0x00005000 +>>> 22484 brk(0x00026000) = 0x00026000 +>>> 22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +>>> 22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +>>> 22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +>>> 22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +>>> 22484 exit(0) +>>> = 0 +>>> 22484 fstat64(1,0x7fffef48) = 0 +>>> 22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 +>>> = 42 +>>> 22484 exit_group(1) +>>> sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +>>> 22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +>>> 22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +>>> 22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +>>> 22484 close(3) = 0 +>>> 22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +>>> 22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +>>> 22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +>>> 22484 mprotect(0x00003000,4096,PROT_READ) = 0 +>>> 22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +>>> 22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +>>> 22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +>>> 22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +>>> 22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +>>> 22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +>>> 22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +>>> 22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +>>> 22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +>>> 22484 brk(NULL) = 0x00005000 +>>> 22484 brk(0x00026000) = 0x00026000 +>>> 22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +>>> 22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +>>> 22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +>>> 22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +>>> 22484 exit(0) +>>> = 0 +>>> 22484 fstat64(1,0x7fffef48) = 0 +>>> 22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 +>>> = 42 +>>> 22484 exit_group(1) +>>> sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +>>> 22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +>>> 22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +>>> 22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +>>> 22484 close(3) = 0 +>>> 22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +>>> 22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +>>> 22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +>>> 22484 mprotect(0x00003000,4096,PROT_READ) = 0 +>>> 22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +>>> 22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +>>> 22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +>>> 22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +>>> 22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +>>> 22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +>>> 22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +>>> 22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +>>> 22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +>>> 22484 brk(NULL) = 0x00005000 +>>> 22484 brk(0x00026000) = 0x00026000 +>>> 22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +>>> 22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +>>> 22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +>>> 22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +>>> 22484 exit(0) +>>> = 0 +>>> 22484 fstat64(1,0x7fffef48) = 0 +>>> 22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 +>>> = 42 +>>> 22484 exit_group(1) +>>> +>>> Note that set_robust_list and clone are reported as unimplemented. +>>> +>>> I've reported the problems with the signal syscalls separately here. +>>> https://bugs.launchpad.net/qemu/+bug/1791763 +>>> +>>> ** Affects: qemu +>>> Importance: Undecided +>>> Status: New +>> +>> +>> -- +>> Alex Bennée +>> + + +-- +Alex Bennée + + +Hi, + +tl;dr Nios II linux-user seems pretty broken + +Following up on some mailing list queries about the state of Nios II +Thomas pointed out that buildroot could build cross-compilers for the +architecture. As a quick experiment I've enabled a docker based +buildroot and turned on tests/tcg for it. + +The results are not very encouraging as both linux-test and test-mmap +fail although (impressively?) testthread passes. + +The test-mmap failure looks like some sort of argument mangling +failure as arg6 of target_mmap looks negative/big and hence causes the +mmap to fail. I tried messing with the #ifdef mangling logic in +do_syscall1 but failed to get it working. + +The linux-test failure seems like a missing lseek system call but I +have no doubt there are others given the bug reports on list. + +This series includes a hack to min uname which we can't really merge. +This is because buildroot is focused on building system images so sets +the glibc minimum kernel version to whatever it builds for the system +image. I leave the problem of programatically tuning the +qemu_nios2_10m50_defconfig to build a general purpose glibc to whoever +wants to take this forward. + +As I'm not particularly interested in this architecture I don't intend +to spend any more time on this. Given how broken linux-user is I +suspect most users of QEMU's Nios 2 emulation use softmmu. If there is +interest in fixing up linux-user then the docker and test/tcg patches +can be included when the fixups are sent to the list. I would argue +that any linux-user target should at the very least pass all of +tests/tcg/multiarch - it's not super comprehensive but it's all we +have at the moment. Perhaps we should consider deprecating the +obviously less used linux-user targets? + +Alex Bennée (4): + docker: add debian-buildroot-base + docker: add buildroot-nios2-cross image + linux-user/nios2: bump min uname to 4.16.0 [!HACK] + tests/tcg: add nios2 architecture (NEEDS FIXES) + + linux-user/nios2/target_syscall.h | 2 +- + tests/docker/Makefile.include | 6 ++++- + .../dockerfiles/buildroot-nios2-cross.docker | 10 +++++++ + .../dockerfiles/debian-buildroot-base.docker | 26 +++++++++++++++++++ + tests/tcg/nios2/Makefile.include | 2 ++ + 5 files changed, 44 insertions(+), 2 deletions(-) + create mode 100644 tests/docker/dockerfiles/buildroot-nios2-cross.docker + create mode 100644 tests/docker/dockerfiles/debian-buildroot-base.docker + create mode 100644 tests/tcg/nios2/Makefile.include + +-- +2.17.1 + + + +We can build some more cross-compilers using buildroot. This base +system contains simply the minimum number of tools required for +buildroot to work. We also download and unpack the buildroot source +tree as that will be common for all system deriving from it. + +Signed-off-by: Alex Bennée <email address hidden> +--- + tests/docker/Makefile.include | 2 +- + .../dockerfiles/debian-buildroot-base.docker | 26 +++++++++++++++++++ + 2 files changed, 27 insertions(+), 1 deletion(-) + create mode 100644 tests/docker/dockerfiles/debian-buildroot-base.docker + +diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include +index d3101afecd..74a82de48a 100644 +--- a/tests/docker/Makefile.include ++++ b/tests/docker/Makefile.include +@@ -6,7 +6,7 @@ DOCKER_SUFFIX := .docker + DOCKER_FILES_DIR := $(SRC_PATH)/tests/docker/dockerfiles + DOCKER_DEPRECATED_IMAGES := debian + # we don't run tests on intermediate images (used as base by another image) +-DOCKER_PARTIAL_IMAGES := debian debian8 debian9 debian8-mxe debian-ports debian-sid debian-bootstrap ++DOCKER_PARTIAL_IMAGES := debian debian8 debian9 debian8-mxe debian-ports debian-sid debian-bootstrap debian-buildroot-base + DOCKER_IMAGES := $(filter-out $(DOCKER_DEPRECATED_IMAGES),$(sort $(notdir $(basename $(wildcard $(DOCKER_FILES_DIR)/*.docker))))) + DOCKER_TARGETS := $(patsubst %,docker-image-%,$(DOCKER_IMAGES)) + # Use a global constant ccache directory to speed up repetitive builds +diff --git a/tests/docker/dockerfiles/debian-buildroot-base.docker b/tests/docker/dockerfiles/debian-buildroot-base.docker +new file mode 100644 +index 0000000000..c4a29abadd +--- /dev/null ++++ b/tests/docker/dockerfiles/debian-buildroot-base.docker +@@ -0,0 +1,26 @@ ++# ++# Buildroot base setup on Debian ++# ++ ++FROM debian:stretch-slim ++ENV BUILDROOT_VERSION=2018.08 ++ ++# Duplicate deb line as deb-src ++RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >> /etc/apt/sources.list ++ ++# Install common build utilities ++RUN apt update && DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata ++RUN DEBIAN_FRONTEND=noninteractive eatmydata \ ++ apt install -y bc \ ++ build-essential \ ++ cpio \ ++ file \ ++ python \ ++ unzip \ ++ rsync \ ++ wget ++ ++# Grab the current buildroot version and unpack in /opt ++RUN mkdir -p /opt ++RUN cd /opt && wget https://buildroot.org/downloads/buildroot-${BUILDROOT_VERSION}.tar.gz ++RUN cd /opt && tar -xvf buildroot-${BUILDROOT_VERSION}.tar.gz +-- +2.17.1 + + + +Build a buildroot toolchain for the nios2 target. + +Signed-off-by: Alex Bennée <email address hidden> +--- + tests/docker/Makefile.include | 4 ++++ + tests/docker/dockerfiles/buildroot-nios2-cross.docker | 10 ++++++++++ + 2 files changed, 14 insertions(+) + create mode 100644 tests/docker/dockerfiles/buildroot-nios2-cross.docker + +diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include +index 74a82de48a..a8dfde8ed5 100644 +--- a/tests/docker/Makefile.include ++++ b/tests/docker/Makefile.include +@@ -120,6 +120,10 @@ docker-image-debian-riscv64-cross: docker-image-debian-sid + docker-image-debian-powerpc-cross: docker-image-debian-sid + docker-image-travis: NOUSER=1 + ++# Buildroot base images ++# These involve building the toolchains and can take some time ++docker-image-buildroot-nios2-cross: docker-image-debian-buildroot-base ++ + # Specialist build images, sometimes very limited tools + docker-image-tricore-cross: docker-image-debian9 + +diff --git a/tests/docker/dockerfiles/buildroot-nios2-cross.docker b/tests/docker/dockerfiles/buildroot-nios2-cross.docker +new file mode 100644 +index 0000000000..e573f0fa55 +--- /dev/null ++++ b/tests/docker/dockerfiles/buildroot-nios2-cross.docker +@@ -0,0 +1,10 @@ ++# ++# NIOS II toolchain ++# ++FROM qemu:debian-buildroot-base ++ ++RUN cd /opt/buildroot-${BUILDROOT_VERSION} && make qemu_nios2_10m50_defconfig ++RUN cd /opt/buildroot-${BUILDROOT_VERSION} && make toolchain ++ ++# The toolchain is in /opt/buildroot-${BUILDROOT_VERSION}/output/host/bin/nios2-* ++RUN ln -s /opt/buildroot-${BUILDROOT_VERSION}/output/host/bin/nios2-* /usr/bin +-- +2.17.1 + + + +This is to work around the limitations of the buildroot +qemu_nios2_10m50_defconfig which sets the base kernel version for +glibc. + +Signed-off-by: Alex Bennée <email address hidden> +--- + linux-user/nios2/target_syscall.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/linux-user/nios2/target_syscall.h b/linux-user/nios2/target_syscall.h +index ca6b7e69f6..905b80d112 100644 +--- a/linux-user/nios2/target_syscall.h ++++ b/linux-user/nios2/target_syscall.h +@@ -2,7 +2,7 @@ + #define TARGET_SYSCALL_H + + #define UNAME_MACHINE "nios2" +-#define UNAME_MINIMUM_RELEASE "3.19.0" ++#define UNAME_MINIMUM_RELEASE "4.16.0" + + struct target_pt_regs { + unsigned long r8; /* r8-r15 Caller-saved GP registers */ +-- +2.17.1 + + + +Now we have a docker image with a nios2 compiler we can add the bits +to build our TCG tests. + +Current failures: + testmmap - fails in check_file_fixed_eof_mmaps due to inversion of offset + linux-test - unimplemented lseek (probably others as well) + +Signed-off-by: Alex Bennée <email address hidden> +--- + tests/tcg/nios2/Makefile.include | 2 ++ + 1 file changed, 2 insertions(+) + create mode 100644 tests/tcg/nios2/Makefile.include + +diff --git a/tests/tcg/nios2/Makefile.include b/tests/tcg/nios2/Makefile.include +new file mode 100644 +index 0000000000..2ab4160435 +--- /dev/null ++++ b/tests/tcg/nios2/Makefile.include +@@ -0,0 +1,2 @@ ++DOCKER_IMAGE=buildroot-nios2-cross ++DOCKER_CROSS_COMPILER=nios2-linux-gcc +-- +2.17.1 + + + +Le 11/09/2018 à 16:06, Alex Bennée a écrit : +> This is to work around the limitations of the buildroot +> qemu_nios2_10m50_defconfig which sets the base kernel version for +> glibc. +> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> linux-user/nios2/target_syscall.h | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/linux-user/nios2/target_syscall.h b/linux-user/nios2/target_syscall.h +> index ca6b7e69f6..905b80d112 100644 +> --- a/linux-user/nios2/target_syscall.h +> +++ b/linux-user/nios2/target_syscall.h +> @@ -2,7 +2,7 @@ +> #define TARGET_SYSCALL_H +> +> #define UNAME_MACHINE "nios2" +> -#define UNAME_MINIMUM_RELEASE "3.19.0" +> +#define UNAME_MINIMUM_RELEASE "4.16.0" +> +> struct target_pt_regs { +> unsigned long r8; /* r8-r15 Caller-saved GP registers */ +> + +I have no objection. Perhaps you could ask NiosII Maintainers (cc). + +Laurent + + + +Laurent Vivier <email address hidden> writes: + +> Le 11/09/2018 à 16:06, Alex Bennée a écrit: +>> This is to work around the limitations of the buildroot +>> qemu_nios2_10m50_defconfig which sets the base kernel version for +>> glibc. +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> linux-user/nios2/target_syscall.h | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/linux-user/nios2/target_syscall.h b/linux-user/nios2/target_syscall.h +>> index ca6b7e69f6..905b80d112 100644 +>> --- a/linux-user/nios2/target_syscall.h +>> +++ b/linux-user/nios2/target_syscall.h +>> @@ -2,7 +2,7 @@ +>> #define TARGET_SYSCALL_H +>> +>> #define UNAME_MACHINE "nios2" +>> -#define UNAME_MINIMUM_RELEASE "3.19.0" +>> +#define UNAME_MINIMUM_RELEASE "4.16.0" +>> +>> struct target_pt_regs { +>> unsigned long r8; /* r8-r15 Caller-saved GP registers */ +>> +> +> I have no objection. Perhaps you could ask NiosII Maintainers (cc). + +Doh.. I had cccmd = scripts/get_maintainer.pl --nogit-fallback but of +course as I didn't actually touch an nios2 files it didn't include them. + +Thanks. + +> +> Laurent + + +-- +Alex Bennée + + +Le 11/09/2018 à 16:40, Alex Bennée a écrit : +> +> Laurent Vivier <email address hidden> writes: +> +>> Le 11/09/2018 à 16:06, Alex Bennée a écrit: +>>> This is to work around the limitations of the buildroot +>>> qemu_nios2_10m50_defconfig which sets the base kernel version for +>>> glibc. +>>> +>>> Signed-off-by: Alex Bennée <email address hidden> +>>> --- +>>> linux-user/nios2/target_syscall.h | 2 +- +>>> 1 file changed, 1 insertion(+), 1 deletion(-) +>>> +>>> diff --git a/linux-user/nios2/target_syscall.h b/linux-user/nios2/target_syscall.h +>>> index ca6b7e69f6..905b80d112 100644 +>>> --- a/linux-user/nios2/target_syscall.h +>>> +++ b/linux-user/nios2/target_syscall.h +>>> @@ -2,7 +2,7 @@ +>>> #define TARGET_SYSCALL_H +>>> +>>> #define UNAME_MACHINE "nios2" +>>> -#define UNAME_MINIMUM_RELEASE "3.19.0" +>>> +#define UNAME_MINIMUM_RELEASE "4.16.0" +>>> +>>> struct target_pt_regs { +>>> unsigned long r8; /* r8-r15 Caller-saved GP registers */ +>>> +>> +>> I have no objection. Perhaps you could ask NiosII Maintainers (cc). +> +> Doh.. I had cccmd = scripts/get_maintainer.pl --nogit-fallback but of +> course as I didn't actually touch an nios2 files it didn't include them. + +I also use "git blame" to know who to bother ;) + +Thanks, +Laurent + + + + +Marek Vasut <email address hidden> writes: + +> On 09/11/2018 04:14 PM, Laurent Vivier wrote: +>> Le 11/09/2018 à 16:06, Alex Bennée a écrit: +>>> This is to work around the limitations of the buildroot +>>> qemu_nios2_10m50_defconfig which sets the base kernel version for +>>> glibc. +>>> +>>> Signed-off-by: Alex Bennée <email address hidden> +>>> --- +>>> linux-user/nios2/target_syscall.h | 2 +- +>>> 1 file changed, 1 insertion(+), 1 deletion(-) +>>> +>>> diff --git a/linux-user/nios2/target_syscall.h b/linux-user/nios2/target_syscall.h +>>> index ca6b7e69f6..905b80d112 100644 +>>> --- a/linux-user/nios2/target_syscall.h +>>> +++ b/linux-user/nios2/target_syscall.h +>>> @@ -2,7 +2,7 @@ +>>> #define TARGET_SYSCALL_H +>>> +>>> #define UNAME_MACHINE "nios2" +>>> -#define UNAME_MINIMUM_RELEASE "3.19.0" +>>> +#define UNAME_MINIMUM_RELEASE "4.16.0" +>>> +>>> struct target_pt_regs { +>>> unsigned long r8; /* r8-r15 Caller-saved GP registers */ +>>> +>> +>> I have no objection. Perhaps you could ask NiosII Maintainers (cc). +> +> If that's needed, so be it. The Linux 3.19 was required because some +> obscure ABI change happened at that point. + +I don't think so - it's an artefact of the way the buildroot toolchain +is built. But the real question which I address in the cover letter is +does nios2-linux-user get much use? I tried enabled tests/tcg for it and +it fails rather badly. + +-- +Alex Bennée + + +If you need a Nios II GNU/Linux toolchain, I think the most recent CodeBench Lite release will work: + +https://sourcery.mentor.com/GNUToolchain/subscription42545 + +We're planning on adding user-mode QEMU to the upcoming 2018.11 release.... that's actually what I've been testing it for. Results on the GCC testsuite actually don't look too bad, but I have a patch I haven't submitted yet that's required to make the GDB stub work, and there are a lot of GDB test failures I haven't triaged yet. + + + +Sandra Loosemore <email address hidden> writes: + +> If you need a Nios II GNU/Linux toolchain, I think the most recent +> CodeBench Lite release will work: +> +> https://sourcery.mentor.com/GNUToolchain/subscription42545 + +Hmm I tried automating that but it seems the installer has GTK +dependencies!? + + Setup: + GTK+ Version Check + Setup: + An error has occurred. See the log file + /root/.mentor/logs/20180911185933/.metadata/.log. + root@0ef91b5e50f2:/opt# cat /root/.mentor/logs/20180911185933/.metadata/.log + !SESSION 2018-09-11 18:59:36.197 ----------------------------------------------- + eclipse.buildId=unknown + java.version=1.8.0_102 + java.vendor=Oracle Corporation + BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US + Framework arguments: -install.once -install.data=/root/.mentor + Command-line arguments: -os linux -ws gtk -arch x86 -install.once -install.data=/root/.mentor -data /root/.mentor/logs/20180911185933 + + !ENTRY org.eclipse.osgi 4 0 2018-09-11 18:59:37.407 + !MESSAGE Application error + !STACK 1 + java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: + /tmp/sourceryg++-2018.05-5-nios2-linux-gnu.bin_sfx.f9eaefb7/installer/configuration/org.eclipse.osgi/148/0/.cp/libswt-pi-gtk-4530.so: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory + no swt-pi-gtk in java.library.path + Can't load library: /root/.swt/lib/linux/x86/libswt-pi-gtk-4530.so + Can't load library: /root/.swt/lib/linux/x86/libswt-pi-gtk.so + /root/.swt/lib/linux/x86/libswt-pi-gtk-4530.so: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory + +Should I just try the tarball approach? + +> We're planning on adding user-mode QEMU to the upcoming 2018.11 +> release.... that's actually what I've been testing it for. Results on +> the GCC testsuite actually don't look too bad, + +OK - I'm a little surprised given the failures I saw in our own +test/tcg/multiarch but it's totally possible that: + + - the buildroot toolchain if foobar + - the (ancient) tests need tweaking + +but it would be nice if we get to a point that QEMU's internal +linux-user tests also pass. + +> but I have a patch I +> haven't submitted yet that's required to make the GDB stub work, and +> there are a lot of GDB test failures I haven't triaged yet. + +When you do post the gdb patch feel free to CC me as I've poked around +in that before. + +-- +Alex Bennée + + + +Marek Vasut <email address hidden> writes: + +> On 09/11/2018 05:08 PM, Alex Bennée wrote: +>> +>> Marek Vasut <email address hidden> writes: +>> +>>> On 09/11/2018 04:14 PM, Laurent Vivier wrote: +>>>> Le 11/09/2018 à 16:06, Alex Bennée a écrit: +<snip> +>> +>> I don't think so - it's an artefact of the way the buildroot toolchain +>> is built. But the real question which I address in the cover letter is +>> does nios2-linux-user get much use? I tried enabled tests/tcg for it and +>> it fails rather badly. +> +> I used it around 2.10 and it worked for me. + +I've just build 2.10.2 (with a patch for memfd and this one) and get the +same failures on the tcg/tests tests. What testing where you running? + +-- +Alex Bennée + + +Hi Alex, + +On 9/11/18 4:06 PM, Alex Bennée wrote: +> We can build some more cross-compilers using buildroot. This base +> system contains simply the minimum number of tools required for +> buildroot to work. We also download and unpack the buildroot source +> tree as that will be common for all system deriving from it. +> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> tests/docker/Makefile.include | 2 +- +> .../dockerfiles/debian-buildroot-base.docker | 26 +++++++++++++++++++ +> 2 files changed, 27 insertions(+), 1 deletion(-) +> create mode 100644 tests/docker/dockerfiles/debian-buildroot-base.docker +> +> diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include +> index d3101afecd..74a82de48a 100644 +> --- a/tests/docker/Makefile.include +> +++ b/tests/docker/Makefile.include +> @@ -6,7 +6,7 @@ DOCKER_SUFFIX := .docker +> DOCKER_FILES_DIR := $(SRC_PATH)/tests/docker/dockerfiles +> DOCKER_DEPRECATED_IMAGES := debian +> # we don't run tests on intermediate images (used as base by another image) +> -DOCKER_PARTIAL_IMAGES := debian debian8 debian9 debian8-mxe debian-ports debian-sid debian-bootstrap +> +DOCKER_PARTIAL_IMAGES := debian debian8 debian9 debian8-mxe debian-ports debian-sid debian-bootstrap debian-buildroot-base +> DOCKER_IMAGES := $(filter-out $(DOCKER_DEPRECATED_IMAGES),$(sort $(notdir $(basename $(wildcard $(DOCKER_FILES_DIR)/*.docker))))) +> DOCKER_TARGETS := $(patsubst %,docker-image-%,$(DOCKER_IMAGES)) +> # Use a global constant ccache directory to speed up repetitive builds +> diff --git a/tests/docker/dockerfiles/debian-buildroot-base.docker b/tests/docker/dockerfiles/debian-buildroot-base.docker +> new file mode 100644 +> index 0000000000..c4a29abadd +> --- /dev/null +> +++ b/tests/docker/dockerfiles/debian-buildroot-base.docker +> @@ -0,0 +1,26 @@ +> +# +> +# Buildroot base setup on Debian +> +# +> + +> +FROM debian:stretch-slim +> +ENV BUILDROOT_VERSION=2018.08 + +To avoid cache invalidate, please move this bellow... + +> + +> +# Duplicate deb line as deb-src +> +RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >> /etc/apt/sources.list +> + +> +# Install common build utilities +> +RUN apt update && DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata +> +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +> + apt install -y bc \ +> + build-essential \ +> + cpio \ +> + file \ +> + python \ +> + unzip \ +> + rsync \ +> + wget +> + +> +# Grab the current buildroot version and unpack in /opt + +... here (or similar around): + + ENV BUILDROOT_VERSION=2018.08 + +> +RUN mkdir -p /opt +> +RUN cd /opt && wget https://buildroot.org/downloads/buildroot-${BUILDROOT_VERSION}.tar.gz +> +RUN cd /opt && tar -xvf buildroot-${BUILDROOT_VERSION}.tar.gz +> + +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +Tested-by: Philippe Mathieu-Daudé <email address hidden> + + +Hi Alex, + +On 9/11/18 4:06 PM, Alex Bennée wrote: +> Build a buildroot toolchain for the nios2 target. +> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> tests/docker/Makefile.include | 4 ++++ +> tests/docker/dockerfiles/buildroot-nios2-cross.docker | 10 ++++++++++ +> 2 files changed, 14 insertions(+) +> create mode 100644 tests/docker/dockerfiles/buildroot-nios2-cross.docker +> +> diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include +> index 74a82de48a..a8dfde8ed5 100644 +> --- a/tests/docker/Makefile.include +> +++ b/tests/docker/Makefile.include +> @@ -120,6 +120,10 @@ docker-image-debian-riscv64-cross: docker-image-debian-sid +> docker-image-debian-powerpc-cross: docker-image-debian-sid +> docker-image-travis: NOUSER=1 +> +> +# Buildroot base images +> +# These involve building the toolchains and can take some time +> +docker-image-buildroot-nios2-cross: docker-image-debian-buildroot-base +> + +> # Specialist build images, sometimes very limited tools +> docker-image-tricore-cross: docker-image-debian9 +> +> diff --git a/tests/docker/dockerfiles/buildroot-nios2-cross.docker b/tests/docker/dockerfiles/buildroot-nios2-cross.docker +> new file mode 100644 +> index 0000000000..e573f0fa55 +> --- /dev/null +> +++ b/tests/docker/dockerfiles/buildroot-nios2-cross.docker +> @@ -0,0 +1,10 @@ +> +# +> +# NIOS II toolchain +> +# +> +FROM qemu:debian-buildroot-base +> + +> +RUN cd /opt/buildroot-${BUILDROOT_VERSION} && make qemu_nios2_10m50_defconfig + +Simply: + + RUN make -C /opt/buildroot-${BUILDROOT_VERSION} qemu_nios2_10m50_defconfig + +> +RUN cd /opt/buildroot-${BUILDROOT_VERSION} && make toolchain + + RUN make -C /opt/buildroot-${BUILDROOT_VERSION} toolchain + +> +# The toolchain is in /opt/buildroot-${BUILDROOT_VERSION}/output/host/bin/nios2-* +> +RUN ln -s /opt/buildroot-${BUILDROOT_VERSION}/output/host/bin/nios2-* /usr/bin + +Similarly: + + ENV PATH $PATH:/opt/buildroot-${BUILDROOT_VERSION}/output/host/bin + +Once build this image takes a bit more than 3GB (this took me 30min to +build). + +With changes: +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +Tested-by: Philippe Mathieu-Daudé <email address hidden> + + + +Philippe Mathieu-Daudé <email address hidden> writes: + +> Hi Alex, +> +> On 9/11/18 4:06 PM, Alex Bennée wrote: +>> Build a buildroot toolchain for the nios2 target. +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> tests/docker/Makefile.include | 4 ++++ +>> tests/docker/dockerfiles/buildroot-nios2-cross.docker | 10 ++++++++++ +>> 2 files changed, 14 insertions(+) +>> create mode 100644 tests/docker/dockerfiles/buildroot-nios2-cross.docker +>> +>> diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include +>> index 74a82de48a..a8dfde8ed5 100644 +>> --- a/tests/docker/Makefile.include +>> +++ b/tests/docker/Makefile.include +>> @@ -120,6 +120,10 @@ docker-image-debian-riscv64-cross: docker-image-debian-sid +>> docker-image-debian-powerpc-cross: docker-image-debian-sid +>> docker-image-travis: NOUSER=1 +>> +>> +# Buildroot base images +>> +# These involve building the toolchains and can take some time +>> +docker-image-buildroot-nios2-cross: docker-image-debian-buildroot-base +>> + +>> # Specialist build images, sometimes very limited tools +>> docker-image-tricore-cross: docker-image-debian9 +>> +>> diff --git a/tests/docker/dockerfiles/buildroot-nios2-cross.docker b/tests/docker/dockerfiles/buildroot-nios2-cross.docker +>> new file mode 100644 +>> index 0000000000..e573f0fa55 +>> --- /dev/null +>> +++ b/tests/docker/dockerfiles/buildroot-nios2-cross.docker +>> @@ -0,0 +1,10 @@ +>> +# +>> +# NIOS II toolchain +>> +# +>> +FROM qemu:debian-buildroot-base +>> + +>> +RUN cd /opt/buildroot-${BUILDROOT_VERSION} && make qemu_nios2_10m50_defconfig +> +> Simply: +> +> RUN make -C /opt/buildroot-${BUILDROOT_VERSION} qemu_nios2_10m50_defconfig +> +>> +RUN cd /opt/buildroot-${BUILDROOT_VERSION} && make toolchain +> +> RUN make -C /opt/buildroot-${BUILDROOT_VERSION} toolchain +> +>> +# The toolchain is in /opt/buildroot-${BUILDROOT_VERSION}/output/host/bin/nios2-* +>> +RUN ln -s /opt/buildroot-${BUILDROOT_VERSION}/output/host/bin/nios2-* /usr/bin +> +> Similarly: +> +> ENV PATH $PATH:/opt/buildroot-${BUILDROOT_VERSION}/output/host/bin +> +> Once build this image takes a bit more than 3GB (this took me 30min to +> build). +> +> With changes: +> Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +> Tested-by: Philippe Mathieu-Daudé <email address hidden> + +Apparently multi-stage builds are meant to help: + + https://docs.docker.com/develop/develop-images/multistage-build/#name-your-build-stages + +It's still a little sub-optimal compared to binary builds but it will do +if we care about supporting every guest architecture with tests. I only +picked nios2 as a random example. + +-- +Alex Bennée + + +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/zero-shot/108/none/1793275 b/results/classifier/zero-shot/108/none/1793275 new file mode 100644 index 000000000..1a86bb4e5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1793275 @@ -0,0 +1,48 @@ +PID: 0.183 +permissions: 0.173 +performance: 0.172 +boot: 0.169 +network: 0.159 +KVM: 0.139 +vnc: 0.129 +device: 0.100 +files: 0.100 +graphic: 0.100 +socket: 0.095 +debug: 0.087 +other: 0.082 +semantic: 0.066 + +Hosts fail to start after update to QEMU 3.0 + +Host OS: Archlinux +Host Architecture: AMD64 +Guest OS: FreeBSD-11.2 (x2) and Archlinux (x1) +Guest Architecture: AMD64 + +I have been using QEMU 2.x without issue for a number of years but since updating to QEMU 3.0 my guests do not complete startup. + +FreeBSD 11.2 guest failure symptom: +The two FreeBSD-11.2 guests output repeated messages of "unexpected cache type 4". This appears to be an internal error message and I've not found any instances of it through Google search. + +Archlinux guest failure symptom: +The single Archlinux guest gets no further than the message "uncompressing initial ramdisk". + +The guests are started by a qemu-kvm invokation. No virtual machine managers are used. The command lines used (from ps awx) to launch the VMs are: + +[neil@optimus ~]$ ps awx |grep qemu + 1492 ? Sl 3:19 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps1.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps1,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_1 -net nic,macaddr=52:54:AD:86:64:00,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.2:23,server,nowait -vnc 192.168.0.1:0 + 1510 ? Sl 0:54 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps2.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps2,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name Archlinux -net nic,macaddr=52:54:AD:86:64:01,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.3:23,server,nowait -vnc 192.168.0.1:1 + 1529 ? Sl 3:07 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps3.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps3,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_2 -net nic,macaddr=52:54:AD:86:64:02,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.4:23,server,nowait -vnc 192.168.0.1:2 + +The VMs were installed to LVM volumes on the host machine (hence the /dev/system/vpsN device names). Networking is over a Linux tap interface connected to a VDE2 virtual network switch. + +Currently working version of QEMU: qemu-headless 2.12.1-1 +Failing version of QEMU: qemu-headless-3.0.0-1 + +Archlinux have released qemu-headless-3.0.0-3 which includes a backported patch for virtio. I have tested this version and the problem still persists. + +This bug is not present in QEMU-3.1.0. + +Ok, thanks for the update. Closing this bug since it seems to be fixed in 3.1. + diff --git a/results/classifier/zero-shot/108/none/1793539 b/results/classifier/zero-shot/108/none/1793539 new file mode 100644 index 000000000..3ef224c38 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1793539 @@ -0,0 +1,31 @@ +device: 0.311 +graphic: 0.284 +semantic: 0.182 +other: 0.089 +PID: 0.062 +socket: 0.061 +performance: 0.057 +vnc: 0.056 +permissions: 0.039 +debug: 0.033 +network: 0.026 +boot: 0.021 +files: 0.014 +KVM: 0.002 + +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 + +During the build of gedit for RISC-V this error occurs: + +$ qemu-riscv64 -E LD_LIBRARY_PATH=gedit/.libs ./gedit/.libs/gedit +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600009e4 + +https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/gedit/standard/riscv64 + +Possibly duplicate of bug #1594394, in which case it would be worth testing with 5.0.0 or above.. + +Actually more likely https://github.com/vivier/qemu-m68k/issues/33, in which case it's also fixed.. + +As you can see in the build log the package builds sucessfully. + diff --git a/results/classifier/zero-shot/108/none/1793791 b/results/classifier/zero-shot/108/none/1793791 new file mode 100644 index 000000000..d979d3dd0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1793791 @@ -0,0 +1,298 @@ +semantic: 0.526 +KVM: 0.504 +other: 0.491 +graphic: 0.477 +debug: 0.472 +performance: 0.457 +permissions: 0.451 +vnc: 0.450 +boot: 0.400 +network: 0.398 +PID: 0.388 +device: 0.371 +socket: 0.291 +files: 0.239 + +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/zero-shot/108/none/1797033 b/results/classifier/zero-shot/108/none/1797033 new file mode 100644 index 000000000..5bf361709 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1797033 @@ -0,0 +1,31 @@ +performance: 0.501 +device: 0.450 +graphic: 0.334 +other: 0.312 +semantic: 0.280 +boot: 0.265 +vnc: 0.239 +socket: 0.187 +files: 0.147 +PID: 0.119 +debug: 0.118 +network: 0.113 +permissions: 0.067 +KVM: 0.057 + +Running with -rtc clock=vm,base=<datetime> introduces arbitrary base shift at guest startup + +When specifying 'base' for RTC to start with, it has incorrect implementation in combination with clock=vm. + +I inspected source code. This is because it uses host clock (qemu_time() function return value) as reference with 'rtc_date_offset' operations across several places in code before guest execution starts, which has no relevance with clock=vm. + +It works in vast majority of cases only thanks to combination of some luck and fast execution of qemu initialization phase relative to host real time (i.e. multiple calls of qemu_time() returns same value). But if qemu execution is being slow down by high CPU load on host or started just before value of second changes, it may accumulate at least 1 second (and in hard circumstances even 2+ seconds) of delay from specified base datetime before guest becomes ready to start. + +This behavior breaks determinism of guest execution in icount mode. (Even if guest doesn't cares about precise time, just one second shift may trigger such chain of changes which accumulates significant difference in guest state at the moment when guest OS finishes booting.) + +Why I didn't posted patch to qemu-devel ? +I have no idea how to patch it correctly, because it isn't clear how these things are expected to work when referenced across all qemu code and different use cases. Should vl.c/qemu_get_timedate() just be fixed ? Does each caller expect same behavior from it? Or only selected hw/* RTC implementations (such as hw/timer/mc146818rtc.c) have to be modified to use alternative function ? Or maybe it isn't specific to clock=vm and should be considered bad behavior in any case (i.e. time shouldn't advance before guest execution being started)? + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=eb6a52099160f1a6e66d7e + diff --git a/results/classifier/zero-shot/108/none/1797262 b/results/classifier/zero-shot/108/none/1797262 new file mode 100644 index 000000000..b6133df31 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1797262 @@ -0,0 +1,56 @@ +boot: 0.583 +device: 0.570 +performance: 0.500 +graphic: 0.491 +files: 0.482 +semantic: 0.446 +socket: 0.426 +permissions: 0.408 +other: 0.286 +network: 0.278 +PID: 0.265 +vnc: 0.222 +debug: 0.166 +KVM: 0.088 + +qemu arm no longer able to boot RPI Kernels + +Since RPi Kernel 1.20170427, qemu is no longer able to emulate the Rasberry Pi, as the linux kernel is complaining about timing issues. + +Old kernel output - https://pastebin.com/wvkneNNF +New kernel output - https://pastebin.com/QTwgCkV2 + +Note that the actual error is caused by the kernel being unable to get the timing source for the mmc (Line 160), which causes an unable-to-mount-root panic. There are other issues with the serial port returning an invalid speed, which displays a divide-by-zero error, which is PROBABLY a symptom of the same root cause. + +This is simple to replicate - The last working kernel is available here: + +https://github.com/raspberrypi/firmware/tree/1.20170405/boot + +Download kernel7 and the dtb, and try to boot with (for example) + +qemu-system-aarch64 -M raspi2 -kernel kernel7.img -dtb bcm2709-rpi-2-b.dtb -serial stdio -sd noobs.img -append "root=/dev/mmcblk0p2 init=/bin/bash" + +This works, and boots successfully. + +However, if you replace the kernel7.img and dtb with ones taken from https://github.com/raspberrypi/firmware/tree/1.20170427/boot it will NOT boot because of various clock timing issues (as in the second paste) + +Isn't this likely due to the newer kernel accessing hardware we are not emulating properly? + +On 19 October 2018 at 12:59, Alex Bennée <email address hidden> wrote: +> Isn't this likely due to the newer kernel accessing hardware we are not +> emulating properly? + +Yes, it will be the missing cprman emulation. There was another +bug/thread on this recently. + +thanks +-- PMM + + +latest series posted: +https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00191.html + +Should be now fixed by commits 74de7145fd6..83ad4695478 (CPRMAN model added). + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/108/none/1798780 b/results/classifier/zero-shot/108/none/1798780 new file mode 100644 index 000000000..ef78bac66 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1798780 @@ -0,0 +1,106 @@ +semantic: 0.468 +permissions: 0.459 +graphic: 0.416 +PID: 0.414 +debug: 0.402 +performance: 0.384 +vnc: 0.381 +other: 0.366 +KVM: 0.329 +device: 0.322 +boot: 0.301 +files: 0.282 +network: 0.278 +socket: 0.268 + +hw/usb/dev-mtp.c:1616: bad test ? + +hw/usb/dev-mtp.c:1616:52: warning: logical ‘or’ of collectively exhaustive tests is always true [-Wlogical-op] + +Source code is + + if ((ret == -1) && (errno != EINTR || errno != EAGAIN || + errno != EWOULDBLOCK)) { + +Maybe better code + + if ((ret == -1) && (errno != EINTR && errno != EAGAIN && + errno != EWOULDBLOCK)) { + +On Fri, 19 Oct 2018 at 10:22, dcb <email address hidden> wrote: +> hw/usb/dev-mtp.c:1616:52: warning: logical ‘or’ of collectively +> exhaustive tests is always true [-Wlogical-op] +> +> Source code is +> +> if ((ret == -1) && (errno != EINTR || errno != EAGAIN || +> errno != EWOULDBLOCK)) { +> +> Maybe better code +> +> if ((ret == -1) && (errno != EINTR && errno != EAGAIN && +> errno != EWOULDBLOCK)) { + +Hi Gerd, Bandan -- I was going through older launchpad bugs and +noticed that this one about a dubious conditional in dev-mtp.c is +still unfixed. + +Is the file descriptor being used here one that's in non-blocking +mode? If so, then busy-waiting in a loop while the write() returns +EWOULDBLOCK is probably not what you wanted. If it's not then +there's no need to check for EAGAIN or EWOULDBLOCK, I think. +Consider using qemu_write_full() instead of open-coding +the retry loop ? + +thanks +-- PMM + + +On Tue, Jan 22, 2019 at 07:41:16AM -0500, Bandan Das wrote: +> +> qemu_write_full takes care of partial blocking writes, +> as in cases of larger file sizes +> +> Suggested-by: Peter Maydell <email address hidden> +> Signed-off-by: Bandan <email address hidden> + +Hmm, doesn't apply, and git fails to do a 3way merge too due to unknown +sha1. + +cheers, + Gerd + + + +On Thu, Jan 24, 2019 at 03:19:03AM -0500, Bandan Das wrote: +> Gerd Hoffmann <email address hidden> writes: +> +> > On Tue, Jan 22, 2019 at 07:41:16AM -0500, Bandan Das wrote: +> >> +> >> qemu_write_full takes care of partial blocking writes, +> >> as in cases of larger file sizes +> >> +> >> Suggested-by: Peter Maydell <email address hidden> +> >> Signed-off-by: Bandan <email address hidden> +> > +> > Hmm, doesn't apply, and git fails to do a 3way merge too due to unknown +> > sha1. +> +> Oops, sorry, I realize now this is on top of the write buffer breakup patches. + +Hmm, they are queued up already, so that should have worked. + +> Should I resend a v2 on top of master and send a v3 for the write buffer breakup +> patches ? + +Can you just send a single series with both this fix and the breakup +patches, against latest master? + +thanks, + Gerd + + + +Fixed by commit 49f9e8d660d4 which will be in QEMU 4.0. + + diff --git a/results/classifier/zero-shot/108/none/1799200 b/results/classifier/zero-shot/108/none/1799200 new file mode 100644 index 000000000..5cf660183 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1799200 @@ -0,0 +1,75 @@ +KVM: 0.508 +other: 0.462 +vnc: 0.454 +device: 0.435 +debug: 0.432 +graphic: 0.429 +permissions: 0.416 +performance: 0.410 +semantic: 0.404 +socket: 0.395 +PID: 0.392 +network: 0.386 +files: 0.365 +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/zero-shot/108/none/1799792 b/results/classifier/zero-shot/108/none/1799792 new file mode 100644 index 000000000..625430991 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1799792 @@ -0,0 +1,49 @@ +graphic: 0.599 +device: 0.539 +performance: 0.459 +other: 0.406 +semantic: 0.302 +debug: 0.291 +boot: 0.259 +network: 0.231 +PID: 0.224 +vnc: 0.223 +permissions: 0.194 +files: 0.190 +socket: 0.182 +KVM: 0.088 + +Broken scaling with gtk,gl=on on a hidpi display + +Tested on QEMU 3.0.0 on Arch Linux. + +I'm using a hidpi screen, and therefore use those environment variables in order to have GTK+ apps properly scaled: + +GDK_SCALE=2 +GDK_DPI_SCALE=0.5 + +However, QEMU, when launched with "-display gtk,gl=on" option, doesn't scale the window content properly, as seen on the attached screenshot. + +Switching to "-display gtk,gl=off" and "-display sdl,gl=on" makes it work fine. + + + +Also happens on Ubuntu 19.10 + +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 happening in QEMU 5.1.0 + +I have the same issue, but unfortunately I cannot work around it: gl=off doesn't work with vfio-display-dmabuf, and sdl segfaults when the guest OS tries to enter GUI. + +unset GDK_SCALE GDK_DPI_SCALE works for me. It was GDK_SCALE=2 GDK_DPI_SCALE=0.5 as KDE would have set. + + +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/262 + + diff --git a/results/classifier/zero-shot/108/none/1802915 b/results/classifier/zero-shot/108/none/1802915 new file mode 100644 index 000000000..7f1825d97 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1802915 @@ -0,0 +1,56 @@ +performance: 0.422 +graphic: 0.362 +semantic: 0.333 +device: 0.275 +socket: 0.201 +PID: 0.191 +debug: 0.184 +vnc: 0.172 +other: 0.160 +files: 0.135 +permissions: 0.131 +boot: 0.120 +network: 0.115 +KVM: 0.062 + +GTK display refresh rate is throttled + +Guest OS running with GL enabled GTK display shows a reduced refresh rate, e.g. moving cursor around with iGVT-g DMA Buf. + +It seems that a default refresh interval GUI_REFRESH_INTERVAL_DEFAULT (30ms) is defined in include/ui/console.h, throttling the display refresh rate at 33Hz. + +To correct this throttle issue, a shorter interval should be applied to display change listener or the default value should be used. + + + +Slow motion clips for host/guest were uploaded as attachments. + +Instead of changing the value, I think there should be a function that determines the ideal "GUI_REFRESH_INTERVAL_DEFAULT" value, with the option to override it. That way, monitor greater than 60 Hz can also benefit. + +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.] + +The bug is still here. + +People are simply modifying the code and recompiling.. It only needs to change the code cap from 30ms (10 years old cap) to 16ms, and we got a smooth gui capable of gaming. + +Please, don't ignore us. Recompiling qemu only for one number is very annoying. + +The ticket has been re-opened here: + + https://gitlab.com/qemu-project/qemu/-/issues/700 + +... so let's keep this one here closed, please. + diff --git a/results/classifier/zero-shot/108/none/1806196 b/results/classifier/zero-shot/108/none/1806196 new file mode 100644 index 000000000..ca65b58ba --- /dev/null +++ b/results/classifier/zero-shot/108/none/1806196 @@ -0,0 +1,42 @@ +graphic: 0.497 +device: 0.451 +files: 0.415 +semantic: 0.405 +network: 0.353 +socket: 0.331 +other: 0.293 +performance: 0.289 +debug: 0.203 +vnc: 0.201 +permissions: 0.190 +boot: 0.183 +PID: 0.178 +KVM: 0.087 + +qed leaked clusters + +There are example of two QED files which AFAIK does not have errors both. But qemu-img check say that one of them has 1 leaked cluster. + +I wrote my own tool and it does not find any error. Both files attached, as well as debug output from my program. + +Both files are about 4G in size after unpacking. Unpack with tar -S to handle sparse files. + +And also, I know, that QED is deprecated, but anyway, seems qemu-img has bug. + + + +Thanks for reporting this. QED is not widely used and its features have been incorporated into qcow2, QEMU's native image format. Since there is no development effort behind QED it is unlikely that this bug will be addressed. Patches are always welcome though! + +I think, this bug also can be triggered in qcow2. Unfortunately it is not so easy for me to find roots of the bug. + +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/264 + + diff --git a/results/classifier/zero-shot/108/none/1808 b/results/classifier/zero-shot/108/none/1808 new file mode 100644 index 000000000..9159a3ca9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1808 @@ -0,0 +1,86 @@ +KVM: 0.381 +graphic: 0.378 +vnc: 0.361 +other: 0.357 +device: 0.340 +debug: 0.329 +performance: 0.318 +boot: 0.312 +permissions: 0.311 +PID: 0.284 +network: 0.282 +semantic: 0.274 +socket: 0.260 +files: 0.252 + +qemu-system-i386: Crash in tcg_handle_interrupt on fpu_raise_exception call +Description of problem: +While I was messing with an old Linux system, QEMU crashed as I tried to run `make test` on a package: +``` +ERROR:../accel/tcg/tcg-accel-ops.c:83:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:83:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +``` +Running QEMU straight from the master branch (c167c80) didn't help either. The backtrace is as follows: +``` +(gdb) bt +#0 0x00007ffff55ac26c in () at /usr/lib/libc.so.6 +#1 0x00007ffff555ca08 in raise () at /usr/lib/libc.so.6 +#2 0x00007ffff5545538 in abort () at /usr/lib/libc.so.6 +#3 0x00007ffff6bae05e in g_assertion_message + (domain=domain@entry=0x0, file=file@entry=0x555555f90a98 "../accel/tcg/tcg-accel-ops.c", line=line@entry=83, func=func@entry=0x55555607a130 <__func__.3> "tcg_handle_interrupt", message=message@entry=0x7fff9c15ee10 "assertion failed: (qemu_mutex_iothread_locked())") at ../glib/glib/gtestutils.c:3450 +#4 0x00007ffff6c0ef40 in g_assertion_message_expr + (domain=domain@entry=0x0, file=file@entry=0x555555f90a98 "../accel/tcg/tcg-accel-ops.c", line=line@entry=83, func=func@entry=0x55555607a130 <__func__.3> "tcg_handle_interrupt", expr=expr@entry=0x555555f79cf8 "qemu_mutex_iothread_locked()") at ../glib/glib/gtestutils.c:3476 +#5 0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:83 +#6 tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:81 +#7 0x0000555555b4d58b in pic_irq_request (opaque=<optimized out>, irq=<optimized out>, level=1) at ../hw/i386/x86.c:555 +#8 0x0000555555b4f218 in gsi_handler (opaque=0x5555579423d0, n=13, level=1) at ../hw/i386/x86.c:611 +#9 0x00007fffa42bde14 in code_gen_buffer () +#10 0x0000555555c724bb in cpu_tb_exec (cpu=cpu@entry=0x555557434cb0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7fffe9bfd658) at ../accel/tcg/cpu-exec.c:457 +#11 0x0000555555c7298e in cpu_loop_exec_tb (tb_exit=0x7fffe9bfd658, last_tb=<synthetic pointer>, pc=3221283547, tb=<optimized out>, cpu=<optimized out>) at ../accel/tcg/cpu-exec.c:919 +#12 cpu_exec_loop (cpu=cpu@entry=0x555557434cb0, sc=sc@entry=0x7fffe9bfd6f0) at ../accel/tcg/cpu-exec.c:1040 +#13 0x0000555555c731dd in cpu_exec_setjmp (cpu=cpu@entry=0x555557434cb0, sc=sc@entry=0x7fffe9bfd6f0) at ../accel/tcg/cpu-exec.c:1057 +#14 0x0000555555c73810 in cpu_exec (cpu=cpu@entry=0x555557434cb0) at ../accel/tcg/cpu-exec.c:1083 +#15 0x0000555555c974ff in tcg_cpus_exec (cpu=cpu@entry=0x555557434cb0) at ../accel/tcg/tcg-accel-ops.c:75 +#16 0x0000555555c97657 in mttcg_cpu_thread_fn (arg=arg@entry=0x555557434cb0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#17 0x0000555555e283e8 in qemu_thread_start (args=0x5555574935f0) at ../util/qemu-thread-posix.c:541 +#18 0x00007ffff55aa44b in () at /usr/lib/libc.so.6 +#19 0x00007ffff562de40 in () at /usr/lib/libc.so.6 +``` + +After further testing, it seems related to inftest.awk. However, the crash doesn't occur right after I run the file, but only when I do specific operations afterwards. + +With `-accel kvm` +``` +> gawk -f test/inftest.awk +(output trimmed) +1e+305 1e+302 +1e+308 1e+305 +gawk: test/inftest.awk:3: fatal: floating point exception +> echo Test # No crash +Test +> cat test/inftest.awk # No crash +``` + +With `-accel tcg` +``` +> gawk -f test/inftest.awk +(output trimmed) +1e+308 1e+305 +Infinity 1e+308 +Infinity Infinity +loop terminated +> echo Test # No crash +Test +> cat test/inftest.awk # QEMU crash +``` +Steps to reproduce: +1. Start the VM +2. Press any key except for enter to go through the SVGA prompt +3. Enter `root` to login. No password is required +4. Run `cd /usr/src2/gawk-2.14` +5. Run `gawk -f test/inftest.awk` +6. Run certain commands that interact with the kernel (ex. `ls`, `cat test/inftest.awk`, `whoami`) +7. Observe the crash +Additional information: +[00000-bootFloppy.raw](/uploads/379f6b601132980af4ea721fe77dbae4/00000-bootFloppy.raw) +[artifact.qcow2](/uploads/d721a35bc55e764e17087e8bc1a7531e/artifact.qcow2) diff --git a/results/classifier/zero-shot/108/none/1808565 b/results/classifier/zero-shot/108/none/1808565 new file mode 100644 index 000000000..24194eb7f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1808565 @@ -0,0 +1,37 @@ +device: 0.597 +semantic: 0.554 +network: 0.526 +graphic: 0.506 +socket: 0.497 +performance: 0.489 +PID: 0.446 +vnc: 0.414 +other: 0.412 +permissions: 0.383 +files: 0.366 +boot: 0.292 +debug: 0.268 +KVM: 0.254 + +Reading /proc/self/task/<pid>/maps is not remapped to the target + +Seeing this in qemu-user 3.1.0 + +The code in is_proc_myself which supports remapping of /proc/self/maps and /proc/<pid>/maps does not support remapping of /proc/self/task/<pid>/maps or /proc/<pid>/task/<pid>/maps. Extending is_proc_myself to cover these cases causes the maps to be rewritten correctly. + +These are useful in multithreaded programs to avoid freezing the entire program to capture the maps for a single tid. + +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. + +Code inspection shows we still don't handle /proc/self/task. + + + +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/222 + + diff --git a/results/classifier/zero-shot/108/none/1812 b/results/classifier/zero-shot/108/none/1812 new file mode 100644 index 000000000..43d2d7f3a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1812 @@ -0,0 +1,40 @@ +other: 0.577 +graphic: 0.523 +semantic: 0.446 +device: 0.444 +performance: 0.428 +PID: 0.322 +debug: 0.295 +network: 0.258 +vnc: 0.254 +permissions: 0.249 +socket: 0.210 +files: 0.194 +boot: 0.184 +KVM: 0.132 + +older programs running under qemu-aarch64 segfaults +Description of problem: +Numerous aarch64 programs segfaults when run under qemu-aarch64. +Steps to reproduce: +1. Install an arm64 chroot (with working qemu-aarch64 binfmt_misc setup): +``` +debootstrap --variant=minbase --arch=arm64 jessie /tmp/jessie-arm64/ http://archive.debian.org/debian +or +debootstrap --variant=minbase --arch=arm64 xenial /tmp/xenial-arm64/ http://ports.ubuntu.com/ +``` +2. build qemu-aarch64; cp qemu-aarch64 /tmp/jessie-arm64/ +3. chroot /tmp/jessie-arm64/ +4. ./qemu-aarch64 /bin/ls +``` +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +``` +Additional information: +Old userspace (eg Debian jessie, Ubuntu xenial) does not work within qemu 8.1-rc2 aarch64 linux-user emulation, since commit 59b6b42cd3446862567637f3a7ab31d69c9bef51 . My guess is that old userspace isn't prepared for recent CPU features, but it still smells strange. + +Not all programs segfaults. dash works, ls or bash does not. + +A chroot is easier in this case, since many old programs don't run inside current environment, like asserting while reading locale-specific information. To run debootstrap and to enter the resulting chroot, a working qemu-aarch64 binfmt_misc setup is needed. + +Reverting the mentioned commit makes everything work again. diff --git a/results/classifier/zero-shot/108/none/1815024 b/results/classifier/zero-shot/108/none/1815024 new file mode 100644 index 000000000..21b0d4eee --- /dev/null +++ b/results/classifier/zero-shot/108/none/1815024 @@ -0,0 +1,42 @@ +device: 0.568 +semantic: 0.558 +socket: 0.532 +vnc: 0.525 +files: 0.472 +performance: 0.466 +PID: 0.462 +network: 0.462 +graphic: 0.386 +permissions: 0.371 +debug: 0.369 +boot: 0.322 +other: 0.220 +KVM: 0.167 + +SIGILL on instruction "stck" under qemu-s390x in user mode + +qemu-s390x in user mode crashes with SIGILL (under host architecture x86_64, running Debian unstable) when executing target instruction "stck" ("STORE CLOCK", see https://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1), which is basically a kind of equivalent of Intel "rdtsc". The same instruction works fine under qemu-s390x in system mode. The bug is reproducible with both the qemu version distributed in Debian unstable and with the latest upstream master (commit 47994e16b1d66411953623e7c0bf0cdcd50bd507). + +This bug manifested itself as a crash of ssh-keygen program, which uses "stck" to obtain some bits of randomness during key creation. Bisection of the code led to the attached minimal example. Compile with (inside an s390x system): + + $ gcc -c -o test.o test.c + $ gcc -c -o rdtsc.o rdtsc.S + $ gcc -o test test.o rdtsc.o + +Then run test. It will crash with SIGILL in user mode and run fine in system mode. Also, compare with the original file at https://github.com/openssl/openssl/blob/master/crypto/s390xcpuid.pl#L139 (there the instruction "stckf" is also used; it is probable that it has the same problem if it is supported altogether, but it did not test for this). + +Running qemu-s390x with options -d in_asm,out_asm,op,op_opt,exec,nochain,cpu gives the trace attached in log.txt. + +Thanks, Giovanni. + + + + + + + +I am also attaching the compiled program, in case it is helpful. + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=965018bea7ce79e1987 + diff --git a/results/classifier/zero-shot/108/none/1815371 b/results/classifier/zero-shot/108/none/1815371 new file mode 100644 index 000000000..ed03ebcf0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1815371 @@ -0,0 +1,57 @@ +other: 0.355 +device: 0.342 +vnc: 0.331 +performance: 0.308 +socket: 0.288 +network: 0.276 +files: 0.212 +graphic: 0.199 +PID: 0.191 +semantic: 0.175 +boot: 0.157 +debug: 0.155 +permissions: 0.117 +KVM: 0.060 + + SPICE session's connection_id's are not unique + +From: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920897 + +===== + +When creating a virtual machine with qemu (e.g. via libvirt) including a SPICE server, the client_id of the SPICE session is not unique. For example, starting multiple virtual machines on the same libvirtd, the client_id is the same for all virtual machine's SPICE sessions. + + +A description of the client_id can be found in + +https://www.spice-space.org/static/docs/spice_protocol.pdf under section 2.11. c) : + + +"UINT32 connection_id - In case of a new session (i.e., channel type is RED_CHANNEL_MAIN) this field is set to zero, and in response the server will allocate session id and will send it via the RedLinkReply message. In case of all other channel types, this field will be equal to the allocated session id" + + +The relevant code for generating client ids in libspice-server1 can be found here: https://gitlab.freedesktop.org/spice/spice/blob/v0.12.8/server/reds.c#L1614 + +This uses rand() to generate the random id, but qemu (at least in the case of qemu-system-x86) fails to initialize the RNG seed (with e.g. srand()). + + +The result is, that every SPICE session started (by e.g. libvirtd) has the same client_id. Usually, this is not a problem, but running something like a SPICE proxy, relying on the client_id to correctly route connections, this creates problems. + + +Adding something like 'srand(time(NULL));' to qemu (in vl.c) solves this issue. Related (as seen in some VNC patches, e.g. 'CVE-2017-15124/04-ui-avoid-pointless-VNC-updates-if-framebuffer-isn-t-.patch/ui/vnc.c' ): srand(time(NULL)+getpid()+getpid()*987654+rand()); + + +Tested on Debian 9.7 with kernel 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux. + + + +===== + + +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/163 + + diff --git a/results/classifier/zero-shot/108/none/1815413 b/results/classifier/zero-shot/108/none/1815413 new file mode 100644 index 000000000..771f76705 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1815413 @@ -0,0 +1,45 @@ +device: 0.597 +other: 0.503 +semantic: 0.445 +PID: 0.374 +performance: 0.283 +network: 0.206 +graphic: 0.200 +debug: 0.131 +boot: 0.085 +socket: 0.076 +permissions: 0.072 +files: 0.067 +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/zero-shot/108/none/1815423 b/results/classifier/zero-shot/108/none/1815423 new file mode 100644 index 000000000..8acdf8a68 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1815423 @@ -0,0 +1,86 @@ +files: 0.577 +other: 0.490 +performance: 0.465 +graphic: 0.458 +debug: 0.446 +device: 0.442 +vnc: 0.394 +socket: 0.392 +network: 0.375 +boot: 0.337 +semantic: 0.333 +permissions: 0.317 +PID: 0.298 +KVM: 0.144 + +x86_64 TCG: Incorrect floating point cast to int. + +I used exaample from: +https://stackoverflow.com/questions/3986795/what-is-the-result-of-casting-float-inf-inf-and-nan-to-integer-in-c + +#include <stdio.h> +#include <math.h> + +int main(int argc, char** argv) { + float a = INFINITY; + float b = -INFINITY; + float c = NAN; + + printf("float %f %f %f\n", a, b, c); + printf("int %d %d %d\n", (int) a, (int) b, (int) c); + printf("uint %u %u %u\n", (unsigned int) a, (unsigned int) b, (unsigned int) c); + printf("lint %ld %ld %ld\n", (long int) a, (long int) b, (long int) b); + printf("luint %lu %lu %lu\n", (unsigned long int) a, (unsigned long int) b, (unsigned long int) c); + + return 0; +} + +And got different results on real computer and on qemu. + +output from real HW is the same as on stackoverflow: + +$ gcc test.c && ./a.out +float inf -inf nan +int -2147483648 -2147483648 -2147483648 +uint 0 0 0 +lint -9223372036854775808 -9223372036854775808 -9223372036854775808 +luint 0 9223372036854775808 9223372036854775808 + + +But on qemu I got another results: + +float inf -inf nan +int 2147483647 -2147483648 2147483647 +uint 4294967295 0 4294967295 +lint 9223372036854775807 -9223372036854775808 -9223372036854775808 +luint 18446744073709551615 9223372036854775808 9223372036854775807 + +qemu launch string: +/qemu-system-x86_64 -m 1024 -cpu core2duo -serial stdio -netdev user,id=network0 -device e1000,netdev=network0 -kernel my_kernel + + +qemu version: +x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-1676-ge47f81b617-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +This bug affect some javascript (surprise) calculations: + +var conversion = "01234567890"; +var x; +var result = conversion[x & 42]; +console.log(result) + + +In example, var x is "undefined" +and when do calculation "x & 42" on js we should get 0 (it is documented feature), but actually got "42" + +and "result" sould be "0" but actually we got "undefined" + +https://<email address hidden>/ is a patch which fixes the C test case (and may also fix the node.js case, though I don't have a setup to test that). + + +This should be fixed by commit 1e8a98b53867f61da9, which will be in the 4.2 release. + + diff --git a/results/classifier/zero-shot/108/none/1817 b/results/classifier/zero-shot/108/none/1817 new file mode 100644 index 000000000..68a554eb8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1817 @@ -0,0 +1,16 @@ +device: 0.521 +semantic: 0.255 +PID: 0.225 +network: 0.221 +graphic: 0.170 +boot: 0.086 +socket: 0.082 +vnc: 0.063 +permissions: 0.062 +files: 0.057 +performance: 0.045 +debug: 0.038 +other: 0.026 +KVM: 0.017 + +meson complains about use of install_subdir in docs/meson.build diff --git a/results/classifier/zero-shot/108/none/1819182 b/results/classifier/zero-shot/108/none/1819182 new file mode 100644 index 000000000..a20034e89 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1819182 @@ -0,0 +1,74 @@ +other: 0.593 +device: 0.517 +semantic: 0.495 +graphic: 0.476 +permissions: 0.468 +vnc: 0.468 +debug: 0.443 +KVM: 0.443 +PID: 0.412 +performance: 0.377 +files: 0.369 +boot: 0.345 +socket: 0.270 +network: 0.255 + +info does not recognize file format of vpc with subformat=fixed + +After creating or converting an image to vpc with 'subformat=fixed' +'qemu-img info' incorrectly identifies the image as 'raw' format. + +$ qemu-img --version +qemu-img version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.10) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ qemu-img create -f vpc -o subformat=fixed my.vpc 2G +Formatting 'my.vpc', fmt=vpc size=2147483648 subformat=fixed + +$ qemu-img info my.vpc +image: my.vpc +file format: raw +virtual size: 2.0G (2147992064 bytes) +disk size: 4.0K + +$ qemu-img info -f vpc my.vpc +image: my.vpc +file format: vpc +virtual size: 2.0G (2147991552 bytes) +disk size: 4.0K + +$ ./go-create +#version: 2.11.1 +qcow: PASS fmt=qcow auto=qcow exp=qcow [name=my-img.qcow opts=] +qcow2: PASS fmt=qcow2 auto=qcow2 exp=qcow2 [name=my-img.qcow2 opts=] +qed: PASS fmt=qed auto=qed exp=qed [name=my-img.qed opts=] +raw: PASS fmt=raw auto=raw exp=raw [name=my-img.raw opts=] +vdi: PASS fmt=vdi auto=vdi exp=vdi [name=my-img.vdi opts=] +vhdx: PASS fmt=vhdx auto=vhdx exp=vhdx [name=my-img.vhdx opts=] +vmdk: PASS fmt=vmdk auto=vmdk exp=vmdk [name=my-img.vmdk opts=] +vpc: PASS fmt=vpc auto=vpc exp=vpc [name=my-img.vpc opts=] +vpc-fixed: FAIL fmt=vpc auto=raw exp=vpc [name=my-img.vpc-fixed opts=-o subformat=fixed] +vpc-fforce: FAIL fmt=vpc auto=raw exp=vpc [name=my-img.vpc-fforce opts=-o subformat=fixed,force_size] +FAIL [2] + +Well, 2.11 is way too old, but it still does reproduce on the latest development head. + + +Suggested patch: +https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg09422.html + +@Thomas, + +Is there really no way to detect the format other than relying on extension? :-( + + +@smoser : fixed-size VHD images don't have a header, and there is AFAIK currently no way for probing a footer in the QEMU code, so relying on the extension seems to be the only way right now, as far as I can tell. + + +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/559 + + diff --git a/results/classifier/zero-shot/108/none/1819649 b/results/classifier/zero-shot/108/none/1819649 new file mode 100644 index 000000000..f78bc5fc7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1819649 @@ -0,0 +1,57 @@ +device: 0.508 +files: 0.394 +PID: 0.360 +semantic: 0.347 +vnc: 0.346 +permissions: 0.296 +performance: 0.286 +network: 0.248 +socket: 0.244 +boot: 0.231 +other: 0.201 +graphic: 0.155 +debug: 0.111 +KVM: 0.066 + +Win10 Preview Build 18351 - no input + +The issue exists in both 2.12.1 and current master (built 8.3.2019). Neither keyboard nor mouse input seems to work and there's no cursor available (VNC, SPICE, SDL tested). If all the 'hv_*' flags are removed input works again. + +In the attachments you can find a simple script to reproduce it (requires the ISO path to be changed). + + + +I can confirm this issue and it also happens with the next (most recent as of today) Windows 10 19h1 insider build number 18353. + +Interestingly, only the x64 version is affected. The 32 bit insider preview seems to work fine with the hv_flags you've provided. + + +For anyone trying to reproduce this issue: + +The easiest way to create an insider iso image is using the scripts from https://uupdump.ml/ which uses the open source aria2 download utility and a conversion script to build the iso from original Microsoft files. + +E.g. in order to create the Windows 10 x64 19h1 insider build 18353 iso: + +# install dependencies for the conversion script +sudo apt-get install aria2 cabextract wimtools chntpw genisoimage +# download the zip with the download links and conversion scripts for the desired windows edition (get the url from https://uupdump.ml/) +wget 'https://uupdump.ml/get.php?id=d3a6af86-214e-4421-a38b-bd4ede09d74e&pack=en-us&edition=0&autodl=2' -O download_and_convert.zip +# unpack, inspect, download and convert +unzip download_and_convert.zip +chmod +x aria2_download_linux.sh +./aria2_download_linux.sh +# now you have the 18353.1_MULTI_X64_EN-US.ISO + + +Update: Bug is still present with yesterday's released Windows 10 19H1 Insider Preview Build 18356 x64. +The x86 version still works fine however. + +I guess this will soon get urgent since Microsoft will release Windows 1903 sometime in March/April. + +Issue seems to be fixed with Windows 10 19H1 Insider Preview Build 18361 ! + +Quoting from Microsoft's Changelog: +"We fixed an issue preventing certain VMs from being able to install or update Windows Insider Preview builds ..." + +Seems this was no qemu issue after all, please close. + diff --git a/results/classifier/zero-shot/108/none/1821444 b/results/classifier/zero-shot/108/none/1821444 new file mode 100644 index 000000000..0a7f9d722 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1821444 @@ -0,0 +1,168 @@ +other: 0.240 +PID: 0.136 +permissions: 0.115 +graphic: 0.106 +performance: 0.106 +debug: 0.088 +device: 0.081 +KVM: 0.080 +network: 0.063 +semantic: 0.062 +vnc: 0.061 +files: 0.059 +boot: 0.047 +socket: 0.027 + +qemu-ppc (user) incorrectly translates float32 arithmetics + +I'm using qemu-3.1.0 (Gentoo). + +When I was running regression test suite via qemu-ppc for GHC I noticed a few uint32_t<->float32 failures I did not expect to encounter. + +Here is an example + +$ cat a.c +#include <stdio.h> +#include <stdint.h> + +int main() { + volatile uint32_t i = 1; + printf("0x1 = %e\n", *(volatile float*)&i); +} + +$ powerpc-unknown-linux-gnu-gcc -O2 a.c -Wall -o a -fno-strict-aliasing -fno-stack-protector -static && ./a +0x1 = 2.802597e-45 + +$ scp a timberdoodle.ppc64.dev.gentoo.org:~/ +a 100% 826KB 102.0KB/s 00:08 + +$ ssh timberdoodle.ppc64.dev.gentoo.org ./a +0x1 = 1.401298e-45 +$ qemu-ppc ./a +0x1 = 2.802597e-45 + +Looks like off-by-one bit somewhere. I'm not sure if it's FPU instruction or some internals of printf() that are emulated incorrectly. + + + +My native system is x86_64-pc-linux-gnu with a few binfmt_misc handlers wired. +Checking other targets I have locally I get the following: + +affected targets: +- powerpc +- powerpc64 +- powerpc64le +unaffected targets: +- arm +- arm64 +- hppa +- sparc +probably unaffected: +- alpha (maybe it's ok as alpha is not quite an IEEE754 platform) + +Raw log: + +$ for gcc in /usr/bin/*-gcc; do rm -f a; $gcc -O2 a.c -Wall -o a -fno-strict-aliasing -fno-stack-protector 2>/dev/null && ./a 2>/dev/null && echo -n "$gcc: " && file a; done | sort + +0x1 = 1.401298e-45 : /usr/bin/aarch64-unknown-linux-gnu-gcc: a: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/aarch64_be-unknown-linux-gnu-gcc: a: ELF 64-bit MSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64_be.so.1, for GNU/Linux 3.7.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/afl-gcc: a: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped +0x1 = 1.401298e-45 : /usr/bin/armv6j-unknown-linux-gnueabihf-gcc: a: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/armv7a-unknown-linux-gnueabihf-gcc: a: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/hppa-unknown-linux-gnu-gcc: a: ELF 32-bit MSB pie executable, PA-RISC, 1.1 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, with debug_info, not stripped +0x1 = 1.401298e-45 : /usr/bin/hppa2.0-unknown-linux-gnu-gcc: a: ELF 32-bit MSB pie executable, PA-RISC, 1.1 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, with debug_info, not stripped +0x1 = 1.401298e-45 : /usr/bin/m68k-unknown-linux-gnu-gcc: a: ELF 32-bit MSB pie executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/mips64-unknown-linux-gnuabin64-gcc: a: ELF 64-bit MSB pie executable, MIPS, MIPS-III version 1 (SYSV), dynamically linked, interpreter /lib64/ld.so.1, for GNU/Linux 3.2.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/riscv64-unknown-linux-gnu-gcc: a: ELF 64-bit LSB pie executable, UCB RISC-V, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-riscv64-lp64d.so.1, for GNU/Linux 4.15.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/s390x-unknown-linux-gnu-gcc: a: ELF 64-bit MSB pie executable, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/sparc-unknown-linux-gnu-gcc: a: ELF 32-bit MSB pie executable, SPARC32PLUS, V8+ Required, total store ordering, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/x86_64-HEAD-linux-gnu-gcc: a: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/x86_64-UNREG-linux-gnu-gcc: a: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped +0x1 = 1.401298e-45 : /usr/bin/x86_64-pc-linux-gnu-gcc: a: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped + +0x1 = 2.652494e-315 : /usr/bin/alpha-unknown-linux-gnu-gcc: a: ELF 64-bit LSB pie executable, Alpha (unofficial), version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, not stripped + +0x1 = 2.802597e-45 : /usr/bin/powerpc-unknown-linux-gnu-gcc: a: ELF 32-bit MSB pie executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, not stripped +0x1 = 2.802597e-45 : /usr/bin/powerpc64-unknown-linux-gnu-gcc: a: ELF 64-bit MSB pie executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.1, for GNU/Linux 3.2.0, not stripped +0x1 = 2.802597e-45 : /usr/bin/powerpc64le-unknown-linux-gnu-gcc: a: ELF 64-bit LSB pie executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, for GNU/Linux 3.10.0, not stripped + +Shorter example without relying on printf() implementation. Looks like uint32_t<->float<->double transitions are enough. + +$ cat a.c +#include <stdio.h> +#include <stdint.h> + +int main() { + volatile uint32_t i = 1; + volatile float f; + volatile double d; + *(volatile uint32_t*)&f = i; + d = f; f = d; // double conversion + i = *(volatile uint32_t*)&f; + printf("0x1 = %x\n", i); +} + +$ powerpc-unknown-linux-gnu-gcc -O2 a.c -Wall -o a -fno-strict-aliasing -fno-stack-protector -static && qemu-ppc ./a +0x1 = 2 + +A bit more investigation: + +It looks like the bug happens in float->double conversion direction. + +$ cat a.c +#include <stdio.h> +#include <stdint.h> + +int main() { + volatile uint32_t i = 1; + volatile float f; + volatile double d; + *(volatile uint32_t*)&f = i; + d = f; + printf("d = %#llx (expect 0x36a0000000000000)\n", *(volatile uint64_t*)&d); +} + +$ powerpc-unknown-linux-gnu-gcc -O2 a.c -Wall -o a -fno-strict-aliasing -fno-stack-protector -static && qemu-ppc ./a +d = 0x36b0000000080000 (expect 0x36a0000000000000) + +10000400 <main>: +10000404: 39 20 00 01 li r9,1 +... +10000434: 91 21 00 10 stw r9,16(r1) +... +1000043c: c0 01 00 10 lfs f0,16(r1) +10000440: d8 01 00 08 stfd f0,8(r1) +... +10000448: 80 a1 00 08 lwz r5,8(r1) +1000044c: 80 c1 00 0c lwz r6,12(r1) +... +10000454: 48 02 01 ad bl 10020600 <___printf_chk> + +This is just lfs/stfd conversion. qemu does translates that pair if instructions into: +$ ppc-linux-user/qemu-ppc -d in_asm,out_asm,op,op_opt /tmp/b/a +... +IN: main +... +0x1000043c: c0010010 lfs f0, 0x10(r1) +0x10000440: d8010008 stfd f0, 8(r1) +... +OP: + ---- 1000043c + movi_i32 tmp1,$0x10 + add_i32 tmp0,r1,tmp1 + qemu_ld_i32 tmp1,tmp0,beul,2 + call todouble,$0x5,$1,tmp2,tmp1 + st_i64 tmp2,env,$0x9198 + +'todouble' must be a 'uint64_t helper_todouble(uint32_t arg=0x1)' from: + https://github.com/qemu/qemu/blob/master/target/ppc/fpu_helper.c#L55 + +Attaching the patch and sending for review as: + https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06562.html + +Alternatively 'uint64_t helper_todouble(uint32_t)' could be implemented via + include/fpu/softfloat.h:float64 float32_to_float64(float32, float_status *status); + + +fix committed with c0e6616b6685ffdb4c5e091bc152e46e14703dd1 and released with 4.2.0 + diff --git a/results/classifier/zero-shot/108/none/1824331 b/results/classifier/zero-shot/108/none/1824331 new file mode 100644 index 000000000..3226a2bb7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1824331 @@ -0,0 +1,86 @@ +other: 0.584 +device: 0.539 +network: 0.506 +semantic: 0.501 +performance: 0.499 +graphic: 0.491 +debug: 0.480 +KVM: 0.469 +permissions: 0.452 +PID: 0.446 +socket: 0.432 +files: 0.417 +vnc: 0.409 +boot: 0.392 + +Qemu Crashes + +A high volume of communication (UDPv4) between the host and Qemu causes it to crash. +Qemu version: 2.11.1 +Ubuntu 18.04.1 LTS + +I attached GDB to the Qemu but wasn't able to get the debug symbols working. +Some more assistance with how to get this working is appreciated (I am new to all of this). + +I recorded two different situations where it happened. Both seem to be related to the network. + +#0 0x00007fa065fb6e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fa065fb8801 in __GI_abort () at abort.c:79 +#2 0x00007fa066001897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fa06612eb9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181 +#3 0x00007fa06600890a in malloc_printerr (str=str@entry=0x7fa06612ccba "corrupted double-linked list") at malloc.c:5350 +#4 0x00007fa066008ac4 in malloc_consolidate (av=av@entry=0x7fa04c000020) at malloc.c:4456 +#5 0x00007fa06600c7d8 in _int_malloc (av=av@entry=0x7fa04c000020, bytes=bytes@entry=8192) at malloc.c:3703 +#6 0x00007fa06600f2ed in __GI___libc_malloc (bytes=8192) at malloc.c:3065 +#7 0x0000555c8d2edee8 in sbreserve () +#8 0x0000555c8d2f06f9 in tcp_input () +#9 0x0000555c8d2ec990 in slirp_input () +#10 0x0000555c8d2dc760 in () +#11 0x0000555c8d2d453d in qemu_deliver_packet_iov () +#12 0x0000555c8d2d7392 in qemu_net_queue_send () +#13 0x0000555c8d2d46f6 in () +#14 0x0000555c8d21e4e6 in () +#15 0x0000555c8d21f7ab in () +#16 0x0000555c8d21fc30 in () +#17 0x0000555c8d056b68 in () +#18 0x0000555c8d053ffe in () +#19 0x0000555c8d058ae7 in memory_region_dispatch_write () +#20 0x0000555c8d014d3e in () +#21 0x0000555c8d0677d8 in kvm_cpu_exec () +#22 0x0000555c8d044404 in () +#23 0x00007fa0663706db in start_thread (arg=0x7fa056ffd700) at pthread_create.c:463 +#24 0x00007fa06609988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + +#0 0x00007f6b3b8f4e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f6b3b8f6801 in __GI_abort () at abort.c:79 +#2 0x00007f6b3b93f897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f6b3ba6cb9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181 +#3 0x00007f6b3b94690a in malloc_printerr (str=str@entry=0x7f6b3ba6aed3 "realloc(): invalid next size") at malloc.c:5350 +#4 0x00007f6b3b94b9b4 in _int_realloc (av=av@entry=0x7f6b1c000020, oldp=oldp@entry=0x7f6b1c03d8a0, oldsize=oldsize@entry=38560, nb=nb@entry=40032) at malloc.c:4534 +#5 0x00007f6b3b94ef9b in __GI___libc_realloc (oldmem=0x7f6b1c03d8b0, bytes=40024) at malloc.c:3230 +#6 0x00007f6b3c6d5ae0 in g_realloc () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#7 0x000055dd0f5e6f50 in () +#8 0x000055dd0f5e7238 in m_cat () +#9 0x000055dd0f5e44f1 in ip_input () +#10 0x000055dd0f5e6990 in slirp_input () +#11 0x000055dd0f5d6760 in () +#12 0x000055dd0f5ce53d in qemu_deliver_packet_iov () +#13 0x000055dd0f5d1392 in qemu_net_queue_send () +#14 0x000055dd0f5ce6f6 in () +#15 0x000055dd0f5184e6 in () +#16 0x000055dd0f5197ab in () +#17 0x000055dd0f519c30 in () +#18 0x000055dd0f350b68 in () +#19 0x000055dd0f34dffe in () +#20 0x000055dd0f352ae7 in memory_region_dispatch_write () +#21 0x000055dd0f30ed3e in () +#22 0x000055dd0f3617d8 in kvm_cpu_exec () +#23 0x000055dd0f33e404 in () +#24 0x00007f6b3bcae6db in start_thread (arg=0x7f6b30f17700) at pthread_create.c:463 +#25 0x00007f6b3b9d788f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Could you try reproducing this with the QEMU 4.0 rc3 which we've just put out, please? I have a vague recollection that we fixed a memory leak in the slirp networking in this area. + + +We tested our situation with Qemu 4.0 and we are unable to reproduce the issue. +So it looks like the issue has been fixed in a more recent version. + diff --git a/results/classifier/zero-shot/108/none/1824344 b/results/classifier/zero-shot/108/none/1824344 new file mode 100644 index 000000000..839f70260 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1824344 @@ -0,0 +1,73 @@ +device: 0.543 +semantic: 0.396 +PID: 0.373 +files: 0.369 +network: 0.367 +socket: 0.356 +other: 0.327 +performance: 0.315 +boot: 0.303 +vnc: 0.251 +permissions: 0.246 +graphic: 0.236 +debug: 0.226 +KVM: 0.008 + +x86: retf or iret pagefault sets wrong error code + +With a x86_64 or i386 guest, non-KVM, when trying to execute a +"iret/iretq/retf" instruction in userspace with invalid stack pointer +(under a protected mode OS, like Linux), wrong bits are set in the +pushed error code; bit 2 is not set, indicating the error comes from +kernel space. + +If the guest OS is using this flag to decide whether this was a kernel +or user page fault, it will mistakenly decide a kernel has irrecoverably +faulted, possibly causing guest OS panic. + + +How to reproduce the problem a guest (non-KVM) Linux: +Note, on recent Linux kernel version, this needs a CPU with SMAP support +(eg. -cpu max) + +$ cat tst.c +int main() +{ +__asm__ volatile ( +"mov $0,%esp\n" +"retf" +); +return 0; +} + +$ gcc tst.c +$ ./a.out +Killed + + +"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle +kernel NULL pointer dereference...", but it has "recovered" by killing +the faulting process (see attached screenshot). + + +Using self-compiled qemu from git: +commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) +Author: Peter Maydell <email address hidden> +Date: Wed Apr 10 15:38:59 2019 +0100 + + Update version for v4.0.0-rc3 release + + Signed-off-by: Peter Maydell <email address hidden> + + + +This appears to be similar to https://bugs.launchpad.net/qemu/+bug/1866892 (and much simpler) + + +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/265 + + diff --git a/results/classifier/zero-shot/108/none/1824768 b/results/classifier/zero-shot/108/none/1824768 new file mode 100644 index 000000000..f657ac7f8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1824768 @@ -0,0 +1,119 @@ +debug: 0.501 +other: 0.454 +permissions: 0.389 +semantic: 0.388 +device: 0.369 +performance: 0.363 +KVM: 0.350 +PID: 0.348 +boot: 0.346 +network: 0.317 +graphic: 0.276 +vnc: 0.265 +files: 0.193 +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/zero-shot/108/none/1824778 b/results/classifier/zero-shot/108/none/1824778 new file mode 100644 index 000000000..528430e98 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1824778 @@ -0,0 +1,32 @@ +device: 0.493 +semantic: 0.280 +graphic: 0.275 +network: 0.264 +other: 0.245 +PID: 0.236 +files: 0.221 +boot: 0.202 +vnc: 0.194 +socket: 0.151 +permissions: 0.146 +debug: 0.140 +performance: 0.083 +KVM: 0.054 + +PowerPC64: tlbivax does not work for addresses above 4G + +The tlbivax instruction in QEMU does not work for address above 4G. The reason behind this is a simple 32bit trunction of an address. +Changing the argument ea from uint32_t to target_ulong for the function booke206_invalidate_ea_tlb() in target/ppc/mmu_helper.c solves the issue. + +I did not reproduce this using Linux so I have no public example for reproducing it. However it's a pretty straight forward change. + +Issue can be seen in all version of QEMU. + + +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/52 + + diff --git a/results/classifier/zero-shot/108/none/1825207 b/results/classifier/zero-shot/108/none/1825207 new file mode 100644 index 000000000..69fdf6561 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1825207 @@ -0,0 +1,77 @@ +other: 0.482 +boot: 0.481 +device: 0.475 +PID: 0.416 +network: 0.407 +vnc: 0.396 +graphic: 0.390 +permissions: 0.381 +semantic: 0.380 +debug: 0.371 +performance: 0.368 +KVM: 0.367 +socket: 0.326 +files: 0.269 + +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/zero-shot/108/none/1826568 b/results/classifier/zero-shot/108/none/1826568 new file mode 100644 index 000000000..1142237eb --- /dev/null +++ b/results/classifier/zero-shot/108/none/1826568 @@ -0,0 +1,52 @@ +other: 0.593 +device: 0.565 +semantic: 0.515 +socket: 0.288 +files: 0.261 +performance: 0.237 +debug: 0.236 +network: 0.230 +vnc: 0.206 +graphic: 0.178 +PID: 0.173 +permissions: 0.165 +boot: 0.090 +KVM: 0.048 + +RISC-V Disassembler/translator instruction decoding disagreement + + +When running QEMU V3.1.0 for platform RISC-V, 64bit, Spike V1.10 with "-d in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this message in the logs: + + 0x000000008002cade: 051300009517e2bf illegal + Disassembler disagrees with translator over instruction decoding + Please report this to <email address hidden> + + +You may want to resolve the disagreement. + +Axel + +Hi Axel, + +can you link us to your test code, such that we can try to reproduce it. + +Cheers, +Bastian + +Sorry, I don't have the test code, since this was created by a memory corruption. However, the way I understand the message is, that there is some internal disagreement how to decode the op-code "051300009517e2bf" - which mige be an invalid opcode anyway. So a simple test application would just consist of this opcode. + +I've encountered this message before for invalid instructions, and it often doesn't really mean there was an error. In particular for variable instruction length ISAs you'll see the error if the translator reads part of the insn and determines that it's invalid without needing to read the rest of it -- https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06845.html talks about a case of that for x86. + + +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/53 + + diff --git a/results/classifier/zero-shot/108/none/1828608 b/results/classifier/zero-shot/108/none/1828608 new file mode 100644 index 000000000..3da4c756b --- /dev/null +++ b/results/classifier/zero-shot/108/none/1828608 @@ -0,0 +1,58 @@ +socket: 0.574 +semantic: 0.536 +device: 0.531 +other: 0.446 +performance: 0.409 +network: 0.377 +permissions: 0.342 +vnc: 0.289 +PID: 0.289 +graphic: 0.228 +files: 0.210 +boot: 0.196 +debug: 0.155 +KVM: 0.153 + +Chardev websocket might not support pasting more than a few chars + +When sending more than 4-5 characters on the websocket serial console (with pasting for example), the guest might not receive all of them, or worse interpret the input as Magic SysRq keys. + +This might be due to the io loop not checking the backend readiness before calling the read function. + +Attached patched fixes the problem on my system. I'm not sure it's the proper approach, this is just to start discussion. + + + +If the problem only happens with a websockets channel enabled, it possibly a bug in the QIOChannelWebsock impl rather than the chardev + +I wrote a websocket client to help reproduce the bug without a browser: +https://github.com/anisse/websocktty + +You can install it to your $GOPATH/bin (defaults to ~/go/bin) with "go get github.com/anisse/websocktty" + +I can reproduce the bug with it by simply pasting a long-enough (5 to 20 characters) string. + +I could not reproduce the bug with qemu's "-serial tcp" and netcat, so this problem might indeed be limited to the websock channel implementation. + +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. + +The bug is still present. + + +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/133 + + diff --git a/results/classifier/zero-shot/108/none/1828723 b/results/classifier/zero-shot/108/none/1828723 new file mode 100644 index 000000000..fc185c8e3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1828723 @@ -0,0 +1,47 @@ +other: 0.499 +graphic: 0.384 +semantic: 0.340 +performance: 0.281 +device: 0.266 +socket: 0.193 +network: 0.165 +permissions: 0.149 +files: 0.133 +vnc: 0.109 +PID: 0.104 +boot: 0.104 +debug: 0.063 +KVM: 0.056 + +[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/zero-shot/108/none/1828867 b/results/classifier/zero-shot/108/none/1828867 new file mode 100644 index 000000000..00c48b42b --- /dev/null +++ b/results/classifier/zero-shot/108/none/1828867 @@ -0,0 +1,50 @@ +device: 0.454 +socket: 0.435 +performance: 0.306 +PID: 0.282 +network: 0.264 +vnc: 0.258 +graphic: 0.231 +semantic: 0.225 +boot: 0.171 +other: 0.169 +permissions: 0.151 +files: 0.128 +KVM: 0.124 +debug: 0.080 + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF + +When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly. +These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers. +On hardware the REX prefix doesn't effect behaviour of these instructions at all. +QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage. + +I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed" + + + +Here's also a basic test that can be run on hardware and have rflags and rsp inspected after each instruction just to see how hardware doesn't effect it. + +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 still relevant. + + +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/130 + + diff --git a/results/classifier/zero-shot/108/none/1831115 b/results/classifier/zero-shot/108/none/1831115 new file mode 100644 index 000000000..36f65cf4e --- /dev/null +++ b/results/classifier/zero-shot/108/none/1831115 @@ -0,0 +1,165 @@ +boot: 0.588 +device: 0.543 +KVM: 0.537 +vnc: 0.506 +other: 0.483 +performance: 0.477 +graphic: 0.406 +permissions: 0.371 +files: 0.350 +network: 0.337 +socket: 0.328 +debug: 0.304 +PID: 0.294 +semantic: 0.288 + +qemu 4.0.0 on aarch64: uefi firmware oversize + +I'd like to enable uefi in my virtual machine, however qemu is always showing the same error: qemu-system-aarch64: Initialization of device cfi.pflash01 failed: device requires 67108864 bytes, block backend provides 786432 bytes +It's clearly impossible to fit a uefi firmware into 786432 bytes. + +Environment: qemu-system-aarch64 with kvm on an amlogic s905d aarch64 dev board, running archlinuxarm, qemu in the repository is compiled with https://download.qemu.org/qemu-4.0.0.tar.xz + +(My AAVMF_CODE.fd and AAVMF_VARS.fd are extracted from debian package qemu-efi-aarch64 0~20181115.85588389-3) + +Below is my libvirt log. + +2019-05-30 15:07:44.216+0000: starting up libvirt version: 5.3.0, qemu version: 4.0.0, kernel: 4.19.46-1-ARCH, hostname: jerry-n1.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-2-debiantesting \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-debiantesting/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-debiantesting/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-debiantesting/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-aarch64 \ +-name guest=debiantesting,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-debiantesting/master-key.aes \ +-machine virt-4.0,accel=kvm,usb=off,dump-guest-core=off,gic-version=2 \ +-cpu host \ +-drive file=/opt/ovmf/aarch64/AAVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ +-drive file=/var/lib/libvirt/qemu/nvram/debiantesting_VARS.fd,if=pflash,format=raw,unit=1 \ +-m 1024 \ +-overcommit mem-lock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid 508d100a-b4e5-4199-9ff9-ac6d40fe2896 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=25,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-reboot \ +-boot strict=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 qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.3,addr=0x0 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 \ +-drive file=/mnt/hddp1/jerry/libvirt/aarch64-images/debiantesting.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 \ +-drive file=/mnt/hddp1/jerry/libvirt/aarch64-iso/debian-testing-arm64-netinst.iso,format=raw,if=none,id=drive-scsi0-0-0-1,readonly=on \ +-device scsi-cd,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 \ +-netdev tap,fd=27,id=hostnet0 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:d5:28:6d,bus=pci.1,addr=0x0 \ +-chardev pty,id=charserial0 \ +-serial chardev:charserial0 \ +-chardev socket,id=charchannel0,fd=28,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-object rng-random,id=objrng0,filename=/dev/urandom \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.5,addr=0x0 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2019-05-30 15:07:44.216+0000: Domain id=2 is tainted: host-cpu +char device redirected to /dev/pts/2 (label charserial0) +2019-05-30T15:07:46.701125Z qemu-system-aarch64: Initialization of device cfi.pflash01 failed: device requires 67108864 bytes, block backend provides 786432 bytes +2019-05-30 15:07:46.779+0000: shutting down, reason=failed +(END) + +# /etc/libvirt/qemu.conf +nvram = [ + "/opt/ovmf/aarch64/AAVMF_CODE.fd:/opt/ovmf/aarch64/AAVMF_VARS.fd" +] + +This is a bug in the debian package that you mention. The 2MB firmware executable (QEMU_EFI.fd) and the 768KB varstore template (QEMU_VARS.fd) that the edk2 ArmVirtQemu platform build produces cannot be passed directly to QEMU. Both files have to be padded to 64MB first. The padding is generally done in the distro-specific package (RPM, DEB etc) build script. + +(If this report mentioned Ubuntu, we could simply re-classify the bug within Launchpad. However, Debian is tracked at bugs.debian.org, so I'll have to close the present issue as Invalid. Please open a bug at bugs.debian.org.) + +Note that starting with version 4.1, upstream QEMU too will bundle firmware binaries from the edk2 project. See https://wiki.qemu.org/ChangeLog/4.1#Miscellaneous + + +[jerry@jerry-n1 aarch64]$ du -b * +67108864 AAVMF_CODE.fd +67108864 AAVMF_VARS.fd +67108864 QEMU_EFI.fd +67108864 QEMU_VARS.fd + +2097152 QEMU_EFI.fd.orig +786432 QEMU_VARS.fd.orig + + +Both files have been padded to 64MB. (if padding means filling it with /dev/zero) + +QEMU_EFI.fd and QEMU_VARS.fd are built by myself according to https://wiki.linaro.org/LEG/UEFIforQEMU. With the self-built formware, I'm getting almost the same error: qemu-system-aarch64: Initialization of device cfi.pflash01 failed: device requires 67108864 bytes, block backend provides 786432 bytes + + +I'm quite sure that debian has done the padding procedure https://salsa.debian.org/qemu-team/edk2/blob/debian/debian/rules#L82 + + +Jerry <email address hidden> writes: + +> [jerry@jerry-n1 aarch64]$ du -b * +> 67108864 AAVMF_CODE.fd +> 67108864 AAVMF_VARS.fd +> 67108864 QEMU_EFI.fd +> 67108864 QEMU_VARS.fd +> +> 2097152 QEMU_EFI.fd.orig +> 786432 QEMU_VARS.fd.orig +> +> +> Both files have been padded to 64MB. (if padding means filling it with +> /dev/zero) + +You can use: + + truncate -s 64m /path/to/blob + +> +> QEMU_EFI.fd and QEMU_VARS.fd are built by myself according to +> https://wiki.linaro.org/LEG/UEFIforQEMU. With the self-built formware, +> I'm getting almost the same error: qemu-system-aarch64: Initialization +> of device cfi.pflash01 failed: device requires 67108864 bytes, block +> backend provides 786432 bytes + +Are you sure your libvirt invocation is properly pointing at your new +re-sized blobs? WFM here on master: + + ./aarch64-softmmu/qemu-system-aarch64 -cpu max -machine type=virt,virtualization=on -display none -m 4096 -serial mon:stdio -netdev user,id=unet,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=unet -device virtio-scsi-pci -blockdev driver=raw,node-name=hd,discard=unmap,file.driver=host_device,file.filename=/dev/zen-disk/debian-buster-arm64 -device scsi-hd,drive=hd -bios /usr/share/AAVMF/AAVMF_CODE.fd + +Where: + +ls -l /usr/share/AAVMF/* +-rw-r--r-- 1 root root 67108864 Mar 16 00:37 /usr/share/AAVMF/AAVMF32_CODE.fd +-rw-r--r-- 1 root root 67108864 Mar 16 00:37 /usr/share/AAVMF/AAVMF32_VARS.fd +-rw-r--r-- 1 root root 67108864 Mar 16 00:37 /usr/share/AAVMF/AAVMF_CODE.fd +-rw-r--r-- 1 root root 67108864 Mar 16 00:37 /usr/share/AAVMF/AAVMF_VARS.fd + +-- +Alex Bennée + + +I just noticed that it was a libvirt bug that caused the error. + +-drive file=/opt/ovmf/aarch64/AAVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ +-drive file=/var/lib/libvirt/qemu/nvram/debiantesting_VARS.fd,if=pflash,format=raw,unit=1 \ + +debiantesting_VARS.fd was never removed or replaced after its first creation since the installation errored out. I deleted this file manually and everything is fine now. + +Sorry for your inconvenience. + diff --git a/results/classifier/zero-shot/108/none/1831545 b/results/classifier/zero-shot/108/none/1831545 new file mode 100644 index 000000000..76edab55f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1831545 @@ -0,0 +1,39 @@ +graphic: 0.461 +device: 0.433 +boot: 0.407 +performance: 0.291 +other: 0.274 +semantic: 0.198 +debug: 0.142 +PID: 0.117 +socket: 0.109 +permissions: 0.078 +network: 0.071 +vnc: 0.068 +files: 0.037 +KVM: 0.020 + +"accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host + +As described in https://lists.gnu.org/archive/html/qemu-devel//2019-05/msg07362.html I run into TCG regression in qemu-git. + +Unfortunately, fix from bug https://bugs.launchpad.net/qemu/+bug/1830872 seems to be nonn-effective for my case. + +For reproduction (on 32-bit x86 host, in my case Slackware with gcc 5.5.0): + +./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg + +make (-j5 in my case) + +try to boot any 64-bit kernel: + +x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg + +result is - qemu appear to hang right after "Booting the kernel" line. Decompression (xz) was ok. + +Tested with qemu-git commit e2a58ff493a2e00db3e963c1839c5374500110f2 + +32-bit OS can be booted fine, and -enable-kvm also allow 64 bit kernel/os to boot. + +bug fixed in current git (commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde). Thanks, Alex! + diff --git a/results/classifier/zero-shot/108/none/1832877 b/results/classifier/zero-shot/108/none/1832877 new file mode 100644 index 000000000..42df5ef56 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1832877 @@ -0,0 +1,69 @@ +network: 0.473 +device: 0.375 +graphic: 0.334 +permissions: 0.311 +semantic: 0.243 +files: 0.235 +performance: 0.199 +socket: 0.183 +PID: 0.180 +boot: 0.145 +vnc: 0.086 +other: 0.085 +debug: 0.079 +KVM: 0.045 + +qemu-bridge-helper undocumented and broken + +qemu output: + +access denied by acl file +qemu-system-ppc64: bridge helper failed + +Option description: + + -netdev bridge,id=id[,br=bridge][,helper=helper] + Connect a host TAP network interface to a host bridge device. + + Use the network helper helper to configure the TAP interface and attach it to the bridge. The default network + helper executable is /path/to/qemu-bridge-helper and the default bridge device is br0. + + Examples: + + #launch a QEMU instance with the default network helper to + #connect a TAP device to bridge br0 + qemu-system-i386 linux.img -netdev bridge,id=n1 -device virtio-net,netdev=n1 + + + + #launch a QEMU instance with the default network helper to + #connect a TAP device to bridge qemubr0 + qemu-system-i386 linux.img -netdev bridge,br=qemubr0,id=n1 -device virtio-net,netdev=n1 + + +What is the acl file? What is the interface to qemu-bridge-helper? + +Also this is what bridge.conf contains: + +# Access control file for qemu bridge helper +# Syntax consists of: +# # comment (ignored) +# allow all +# allow <bridge_name> +# deny all +# deny <bridge_name> +# include /path/to/additional/ACL/file +# Users are blacklisted by default and 'deny' takes precedence over 'allow'. +# Including additional ACL files allows file access permissions to be used as +# a component of the policy to allow access or deny access to specific bridges. + +How are users specified? Or is the mention of users bogus? + + +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/177 + + diff --git a/results/classifier/zero-shot/108/none/1832916 b/results/classifier/zero-shot/108/none/1832916 new file mode 100644 index 000000000..c70fa2429 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1832916 @@ -0,0 +1,34 @@ +device: 0.469 +graphic: 0.426 +network: 0.329 +socket: 0.283 +other: 0.253 +semantic: 0.239 +vnc: 0.205 +files: 0.185 +boot: 0.184 +permissions: 0.175 +PID: 0.148 +performance: 0.083 +debug: 0.069 +KVM: 0.034 + +linux-user does not check PROT_EXEC + +At no point do we actually verify that a page is PROT_EXEC before translating. All we end up verifying is that the page is readable. Not the same thing, obviously. + +The following test case should work for any architecture, though I've only validated it for x86_64 and aarch64. + + + +It turns out we can't fix this without also fixing +our implementation of signal trampolines. + + +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/122 + + diff --git a/results/classifier/zero-shot/108/none/1834613 b/results/classifier/zero-shot/108/none/1834613 new file mode 100644 index 000000000..e6df1008a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1834613 @@ -0,0 +1,83 @@ +graphic: 0.298 +PID: 0.297 +other: 0.268 +semantic: 0.226 +permissions: 0.226 +vnc: 0.217 +device: 0.195 +performance: 0.195 +socket: 0.190 +KVM: 0.189 +debug: 0.163 +network: 0.150 +files: 0.127 +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/zero-shot/108/none/1836763 b/results/classifier/zero-shot/108/none/1836763 new file mode 100644 index 000000000..67c7ee327 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1836763 @@ -0,0 +1,134 @@ +KVM: 0.596 +PID: 0.573 +permissions: 0.567 +graphic: 0.552 +files: 0.535 +performance: 0.509 +device: 0.493 +network: 0.478 +boot: 0.465 +vnc: 0.460 +other: 0.445 +debug: 0.433 +socket: 0.375 +semantic: 0.361 + +Firebird crashes on qemu-m68k-user with pthread_mutex_init error + +Trying to use the Firebird database on qemu-m68k-user with a Debian chroot fails with the database crashing with "ConfigStorage: mutex pthread_mutex_init error, status = 95": + +(sid-m68k-sbuild)root@epyc:/# apt install firebird3.0-server +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following packages were automatically installed and are no longer required: + cpio libip4tc0 +Use 'apt autoremove' to remove them. +The following additional packages will be installed: + firebird3.0-common firebird3.0-common-doc firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util +Suggested packages: + firebird3.0-doc +The following NEW packages will be installed: + firebird3.0-common firebird3.0-common-doc firebird3.0-server firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util +0 upgraded, 7 newly installed, 0 to remove and 4 not upgraded. +Need to get 4,051 kB of archives. +After this operation, 15.9 MB of additional disk space will be used. +Do you want to continue? [Y/n] +Get:1 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common-doc all 3.0.5.33100.ds4-3 [35.3 kB] +Get:2 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common all 3.0.5.33100.ds4-3 [14.5 kB] +Get:3 http://ftp.ports.debian.org/debian-ports unstable/main m68k libfbclient2 m68k 3.0.5.33100.ds4-3 [496 kB] +Get:4 http://ftp.ports.debian.org/debian-ports unstable/main m68k libib-util m68k 3.0.5.33100.ds4-3 [3,220 B] +Get:5 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server-core m68k 3.0.5.33100.ds4-3 [2,368 kB] +Get:6 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-utils m68k 3.0.5.33100.ds4-3 [770 kB] +Get:7 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server m68k 3.0.5.33100.ds4-3 [365 kB] +Fetched 4,051 kB in 2s (1,803 kB/s) +debconf: delaying package configuration, since apt-utils is not installed +E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device) +Selecting previously unselected package firebird3.0-common-doc. +(Reading database ... 33605 files and directories currently installed.) +Preparing to unpack .../0-firebird3.0-common-doc_3.0.5.33100.ds4-3_all.deb ... +Unpacking firebird3.0-common-doc (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-common. +Preparing to unpack .../1-firebird3.0-common_3.0.5.33100.ds4-3_all.deb ... +Unpacking firebird3.0-common (3.0.5.33100.ds4-3) ... +Selecting previously unselected package libfbclient2:m68k. +Preparing to unpack .../2-libfbclient2_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking libfbclient2:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package libib-util:m68k. +Preparing to unpack .../3-libib-util_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking libib-util:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-server-core:m68k. +Preparing to unpack .../4-firebird3.0-server-core_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-utils. +Preparing to unpack .../5-firebird3.0-utils_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-utils (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-server. +Preparing to unpack .../6-firebird3.0-server_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-server (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-common-doc (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-common (3.0.5.33100.ds4-3) ... +Setting up libib-util:m68k (3.0.5.33100.ds4-3) ... +Setting up libfbclient2:m68k (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-utils (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-server (3.0.5.33100.ds4-3) ... +debconf: unable to initialize frontend: Dialog +debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) +debconf: falling back to frontend: Readline +Password for firebird 3.0 +------------------------- + +Firebird has a special user named SYSDBA, which is the user that has access to all databases. SYSDBA can also create new databases and users. Because of this, it is +necessary to secure SYSDBA with a password. + +The password is stored in /etc/firebird/3.0/SYSDBA.password (readable only by root). You may modify it there (don't forget to update the security database too, using the +gsec utility), or you may use dpkg-reconfigure to update both. + +If you don't enter a password, a random one will be used (and stored in SYSDBA.password). + +Password for SYSDBA: + +adduser: Warning: The home directory `/var/lib/firebird' does not belong to the user you are currently creating. +ConfigStorage: mutex pthread_mutex_init error, status = 95 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +dpkg: error processing package firebird3.0-server (--configure): + installed firebird3.0-server package post-installation script subprocess returned error exit status 134 +Processing triggers for systemd (241-6+b2) ... +Processing triggers for man-db (2.8.5-2) ... +Not building database; man-db/auto-update is not 'true'. +Processing triggers for libc-bin (2.28-10+qemu) ... +Errors were encountered while processing: + firebird3.0-server +E: Sub-process /usr/bin/dpkg returned an error code (1) +(sid-m68k-sbuild)root@epyc:/# SEC_SQL=/usr/share/firebird/3.0/security.sql T=/tmp/tmp.2kBDCgAevm T_SEC=/tmp/tmp.2kBDCgAevm/security.fdb isql-fb -q +SQL> create database '/tmp/tmp.2kBDCgAevm/security.fdb'; +ConfigStorage: mutex pthread_mutex_init error, status = 95 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +(sid-m68k-sbuild)root@epyc:/# + +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.] + + +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/442 + + diff --git a/results/classifier/zero-shot/108/none/1838228 b/results/classifier/zero-shot/108/none/1838228 new file mode 100644 index 000000000..79e153b0f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1838228 @@ -0,0 +1,43 @@ +graphic: 0.561 +performance: 0.405 +semantic: 0.403 +device: 0.400 +other: 0.362 +network: 0.288 +socket: 0.251 +debug: 0.186 +vnc: 0.124 +permissions: 0.123 +boot: 0.099 +PID: 0.097 +files: 0.080 +KVM: 0.047 + +Slirp Broadcast traffic + +Hi all, + +Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1) + +I'm running some DHCP traffic to a *custom* DHCP server with user-mode networking in QEMU. I'm using port 30067 for the server, so this does not conflict with the built-in DHCP server. + +DHCP broadcasts to and from the server, and I'm observing issues with both sending and receiving packets. + +Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway) makes it to the server, but a packet sent to 255.255.255.255 does not. I'd suspect that Slirp has to support sending to the broadcast IP address? Or is this something I can turn on with a configuration option? (My QEMU version too old?) + +Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by RFC). That means that any return packet will have 0.0.0.0 swapped in as its destination address. However, that packet doesn't make it into the VM at all. I know that if you deliver this packet to Linux, a raw socket will spit it back out. The packets' destination address should not prevent the packet from being delivered to the right VM, since Slirp (should?) know exactly which VM the session belongs to. (It's a proxy, not a router.) + +WDYT? Did I miss some configuration options or use too old a version? + +Thanks, +Chris + +slirp has been moved to a standalone project, can you report here: +https://gitlab.freedesktop.org/slirp/libslirp/issues + +I don't have an answer off the top of my head, but I would suggest looking/tweaking at the network mask. And for the receive side, debugging from sorecvfrom(). + +Thanks. Opened https://gitlab.freedesktop.org/slirp/libslirp/issues/9. + +The ticket in the libslirp tracker has been closed a year ago, so I think we can close this ticket here, too. + diff --git a/results/classifier/zero-shot/108/none/1838658 b/results/classifier/zero-shot/108/none/1838658 new file mode 100644 index 000000000..72e7cadaf --- /dev/null +++ b/results/classifier/zero-shot/108/none/1838658 @@ -0,0 +1,179 @@ +permissions: 0.583 +boot: 0.576 +graphic: 0.564 +network: 0.512 +PID: 0.503 +other: 0.500 +debug: 0.447 +semantic: 0.410 +device: 0.406 +performance: 0.365 +vnc: 0.337 +socket: 0.328 +files: 0.308 +KVM: 0.280 + +qemu 4.0.0 broken by glib update + +In brief, an install CD will successfully boot with qemu 4.0.0 built with glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I tracked it down to glib's GHashTable improvements. qemu is happy with a glib built from +``` + git checkout -f 2.60.4 + git revert --no-edit 86c6f7e2b..3bed8a13b + git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159 + git revert --no-edit 603fb5958..d3074a748 + git revert --no-edit 0b45ddc55..0600dd322 +``` +When the GHashTable improvements were committed, there was already a preemptive note about any breakage being due to using private implementation details, hence mentioning it here rather than with glib. + +For the full saga, see: http://gnats.netbsd.org/54310 + +Fedora 30 has been shipping glib2 2.60.0 through to 2.60.5 and QEMU in general has been working normally AFAICT. + +From the netbsd bug report it looks like the reproducer was demoed using the sparc emulator - is that the only QEMU arch that is affected ? + +The test image that the netbsd bug points to no longer exists. + +If I pick the image currently available: + + http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/images/NetBSD-9.99.2-sparc.iso + +And launch it in a QEMU built from today's GIT master, on Fedora 30 with glib2 2.60.5, NetBSD successfully boots and launches the installer... + + +$ ~/usr/qemu-git/bin/qemu-system-sparc -drive file=NetBSD-9.99.2-sparc.img,format=raw,media=disk,snapshot=off -cdrom /var/lib/libvirt/images/NetBSD-9.99.2-sparc.iso -boot d -nographic +Configuration device id QEMU version 1 machine id 32 +Probing SBus slot 0 offset 0 +Probing SBus slot 1 offset 0 +Probing SBus slot 2 offset 0 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +Probing SBus slot 5 offset 0 +Invalid FCode start byte +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Jul 1 2019 17:08 + Type 'help' for detailed information +Trying cdrom:d... +Not a bootable ELF image +Loading a.out image... +Loaded 65536 bytes +entry point is 0x4000 +bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d +switching to new context: +>> NetBSD/sparc Secondary Boot, Revision 1.15 (Thu Aug 1 22:23:16 UTC 2019) +Booting netbsd +3375564+96668=0x34ffe0 +OBP version 3, revision 2.25 (plugin rev 2) +[ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, +[ 1.0000000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, +[ 1.0000000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved. +[ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993 +[ 1.0000000] The Regents of the University of California. All rights reserved. + +[ 1.0000000] NetBSD 9.99.2 (INSTALL) #0: Thu Aug 1 22:23:16 UTC 2019 +[ 1.0000000] <email address hidden>:/usr/src/sys/arch/sparc/compile/INSTALL +[ 1.0000000] total memory = 111 MB +[ 1.0000000] avail memory = 106 MB +[ 1.0000000] bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d +[ 1.0000000] mainbus0 (root): SUNW,SPARCstation-5: hostid 80123456 +[ 1.0000000] cpu0 at mainbus0: FMI,MB86904 @ 170 MHz, MB86910 or WTL1164/5 FPU +[ 1.0000000] cpu0: 16K instruction (32 b/l), 8K data (16 b/l), 512K external (32 b/l): cache enabled +[ 1.0000000] obio0 at mainbus0 +[ 1.0000000] clock0 at obio0 slot 0 offset 0x200000: mk48t08 +[ 1.0000000] timer0 at obio0 slot 0 offset 0xd00000: delay constant 201, frequency = 2000000 Hz +[ 1.0000050] zs0 at obio0 slot 0 offset 0x100000 level 12 softpri 6 +[ 1.0000050] zstty0 at zs0 channel 0 (console i/o) +[ 1.0000050] zstty1 at zs0 channel 1 +[ 1.0000050] zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6 +[ 1.0000050] zstty2 at zs1 channel 0 +[ 1.0000050] kbd0 at zstty2 +[ 1.0000050] zstty3 at zs1 channel 1 +[ 1.0000050] ms0 at zstty3 +[ 1.0000050] wsmouse0 at ms0 mux 0 +[ 1.0000050] fdc0 at obio0 slot 0 offset 0x400000 level 11 softpri 4: chip 82077 +[ 1.0000050] fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec +[ 1.0000050] auxreg0 at obio0 slot 0 offset 0x900000 +[ 1.0000050] power0 at obio0 slot 0 offset 0x910000 level 2 +[ 1.0000050] slavioconfig at obio0 slot 0 offset 0x800000 not configured +[ 1.0000050] iommu0 at mainbus0 addr 0x10000000: version 0x5/0x0, page-size 4096, range 64MB +[ 1.0000050] sbus0 at iommu0: clock = 21.250 MHz +[ 1.0000050] dma0 at sbus0 slot 5 offset 0x8400000: DMA rev 2 +[ 1.0000050] esp0 at dma0 slot 5 offset 0x8800000 level 4: ESP200, 40MHz, SCSI ID 7 +[ 1.0000050] scsibus0 at esp0: 8 targets, 8 luns per target +[ 1.0000050] ledma0 at sbus0 slot 5 offset 0x8400010: DMA rev 2 +[ 1.0000050] le0 at ledma0 slot 5 offset 0x8c00000 level 6: address 52:54:00:12:34:56 +[ 1.0000050] le0: 8 receive buffers, 2 transmit buffers +[ 1.0000050] tcx0 at sbus0 slot 3 offset 0x800000 level 5 (ipl 9) (8-bit only TCX) +[ 1.0000050] tcx0: SUNW,tcx, 1024 x 768 +[ 1.0000050] tcx0: id 0, rev 0, sense 0 +[ 1.0000050] tcx0: attached to /dev/fb0 +[ 1.0000050] wsdisplay1 at tcx0 kbdmux 1 +[ 1.0000050] SUNW,CS4231 at sbus0 slot 4 offset 0xc000000 level 5 (ipl 9) not configured +[ 1.0000050] power-management at sbus0 slot 4 offset 0xa000000 not configured +[ 1.0000050] scsibus0: waiting 2 seconds for devices to settle... +[ 1.0000050] wskbd0 at kbd0 mux 1 +[ 3.4705415] sd0 at scsibus0 target 0 lun 0: <QEMU, QEMU HARDDISK, 2.5+> disk fixed +[ 3.4805320] sd0: 2048 MB, 4161 cyl, 16 head, 63 sec, 512 bytes/sect x 4194304 sectors +[ 3.4805320] cd0 at scsibus0 target 2 lun 0: <QEMU, QEMU CD-ROM, 2.5+> cdrom removable +[ 4.4805570] kbd0: reset failed +[ 4.5705505] root on md0a dumps on md0b +[ 4.5805965] root file system type: ffs +[ 4.5805965] kern.module.path=/stand/sparc/9.99.2/modules +Welcome to the NetBSD/sparc microroot setup utility. + +We've just completed the first stage of a two-stage procedure to load a +fully functional NetBSD installation environment on your machine. In the +second stage which is to follow now, a set of additional installation +utilities must be load from your NetBSD/sparc installation medium. + +This procedure supports one of the following media: + +1) cdrom +2) tape +3) floppy + +Installation medium to load the additional utilities from: + + +Can you confirm that you can still reproduce the original problem using QEMU git master, and latest NetBSD ISO image. + + +> From the netbsd bug report it looks like the reproducer was demoed +> using the sparc emulator - is that the only QEMU arch that is affected ? + +Only one arch is affected, but it's sparc64, not sparc. + + +> The test image that the netbsd bug points to no longer exists. + +Please try this one instead: + + https://www.gson.org/bugs/qemu/NetBSD-8.99.47-sparc64.iso + +I just verified that this image works for reproducing the bug. + + + +Doh, sorry for my comment earlier where I mistakenly used sparc instead of sparc64. + +I've now tested QEMU git master with that sparc64 ISO and qemu-system-sparc64. + +I still can't reproduce it though - it boots past the disk probing, and into the installer, where it asks for the terminal type. + +So looks like there's some further variable involved beyond just the glib update - perhaps something about the host OS is combining with the glib update to trigger it. + + +> So looks like there's some further variable involved beyond just the +> glib update - perhaps something about the host OS is combining with +> the glib update to trigger it. + +Agreed - I just retested using a Fedora 30 instance on EC2, with +glib2-2.60.1-2.fc30.x86_64, and was also unable to reproduce the +issue there. + + +The linked NetBSD bug report http://gnats.netbsd.org/54310 now has confirmation that this crash was the result of a memory corruption bug in QEMU which happened to manifest with the newer glib version. That bug is fixed in QEMU master in commit ef905eff421c5a06a01 which will be in the 5.2 release, so we can mark this as 'fix committed'. + + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/108/none/1839367 b/results/classifier/zero-shot/108/none/1839367 new file mode 100644 index 000000000..bcd0b6205 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1839367 @@ -0,0 +1,73 @@ +graphic: 0.469 +PID: 0.447 +network: 0.414 +semantic: 0.394 +permissions: 0.383 +device: 0.372 +socket: 0.316 +KVM: 0.295 +boot: 0.291 +vnc: 0.290 +other: 0.288 +files: 0.281 +performance: 0.269 +debug: 0.234 + +Wrong interrupts generated for I.MX6 FEC controller + +The imx_eth_update function in hw/net/imx_fec.c has the following comment (https://github.com/qemu/qemu/blob/864ab314f1d924129d06ac7b571f105a2b76a4b2/hw/net/imx_fec.c#L421-L445): + + /* + * Previous versions of qemu had the ENET_INT_MAC and ENET_INT_MAC + * interrupts swapped. This worked with older versions of Linux (4.14 + * and older) since Linux associated both interrupt lines with Ethernet + * MAC interrupts. Specifically, + * - Linux 4.15 and later have separate interrupt handlers for the MAC and + * timer interrupts. Those versions of Linux fail with versions of QEMU + * with swapped interrupt assignments. + * - In linux 4.14, both interrupt lines were registered with the Ethernet + * MAC interrupt handler. As a result, all versions of qemu happen to + * work, though that is accidental. + * - In Linux 4.9 and older, the timer interrupt was registered directly + * with the Ethernet MAC interrupt handler. The MAC interrupt was + * redirected to a GPIO interrupt to work around erratum ERR006687. + * This was implemented using the SOC's IOMUX block. In qemu, this GPIO + * interrupt never fired since IOMUX is currently not supported in qemu. + * Linux instead received MAC interrupts on the timer interrupt. + * As a result, qemu versions with the swapped interrupt assignment work, + * albeit accidentally, but qemu versions with the correct interrupt + * assignment fail. + * + * To ensure that all versions of Linux work, generate ENET_INT_MAC + * interrrupts on both interrupt lines. This should be changed if and when + * qemu supports IOMUX. + */ + +Unfortunately, this behavior causes the QNX Sabrelite BSP (http://blackberry.qnx.com/en/developers/bsp) to hang on ethernet initialization. This is caused by the fact that QEMU is firing the ENET_INT_TS_TIMER timer interrupt unexpectedly (when the ENET_INT_MAC flag is set). The BSP functions correctly on the actual hardware, but it is unable to handle the deliberately incorrect interrupt firing by QEMU. + +From reading the comment, it appears that this behavior is necessary to support certain versions of Linux. However, it would be very useful to be able to restore the correct interrupt behavior (possibly via a command-line flag). + +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. + + +Still a bug. + + + +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/224 + + diff --git a/results/classifier/zero-shot/108/none/1843795 b/results/classifier/zero-shot/108/none/1843795 new file mode 100644 index 000000000..112fa7781 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1843795 @@ -0,0 +1,70 @@ +device: 0.438 +other: 0.271 +PID: 0.260 +semantic: 0.252 +network: 0.224 +permissions: 0.178 +performance: 0.175 +vnc: 0.173 +graphic: 0.147 +socket: 0.129 +files: 0.098 +debug: 0.087 +boot: 0.063 +KVM: 0.055 + +'mtfsf' instruction can clear FI incorrectly + +Using mtfsf instruction can clear the FPSCR FI bit incorrectly. This code snippet exhibits the issue: +-- + fpscr.ll = 0x1fffffff; + __builtin_mtfsf (0b11111111, fpscr.d); + fpscr.d = __builtin_mffs (); +-- + +On POWER9 hardware: +mffs : FPSCR = 0x000000007ffff7ff + +On qemu (git master; "-cpu POWER9"): +-- +$ ./mtfsf +mffs : FPSCR = 0x000000007ffdffff +-- + +Two differences: +bit 52: "reserved", so maybe a "don't care" case +bit 46: "FI" + +$ git log -1 master +commit 89ea03a7dc83ca36b670ba7f787802791fcb04b1 +Merge: 019217c 2531164 +Author: Peter Maydell <email address hidden> +Date: Mon Sep 9 09:48:34 2019 +0100 + +I tracked the clear is coming from do_float_check_status, likely the one in gen_mtfsf, but then I get lost figuring out what _should_ be happening. :-/ + +Test attached. + + + +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/266 + + diff --git a/results/classifier/zero-shot/108/none/1844814 b/results/classifier/zero-shot/108/none/1844814 new file mode 100644 index 000000000..c8592330a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1844814 @@ -0,0 +1,45 @@ +device: 0.480 +graphic: 0.356 +semantic: 0.317 +socket: 0.295 +files: 0.243 +permissions: 0.227 +PID: 0.225 +performance: 0.221 +network: 0.213 +other: 0.211 +vnc: 0.165 +debug: 0.116 +boot: 0.108 +KVM: 0.080 + +trace: SystemTap documentation out of date + +The docs/devel/tracing.txt help suggest: + + scripts/tracetool.py --backends=dtrace --format=stap \ + --binary path/to/qemu-binary \ + --target-type system \ + --target-name x86_64 \ + <trace-events-all >qemu.stp + +but since commit 2098c56a9bc this comment is outdated: + + $ scripts/tracetool.py --backends=dtrace --format=stap \ + --binary mips-softmmu/qemu-system-mips \ + --target-type system \ + --target-name mips trace-events-all + Error: group name is required + +The offending commit seems: + +commit 2098c56a9bc5901e145fa5d4759f075808811685 +Author: Daniel P. Berrange <email address hidden> +Date: Wed Jan 25 16:14:14 2017 +0000 + + trace: move setting of group name into Makefiles + +Fixed by commit bd200384c515 (trace: add --group=all to tracing.txt). + +Fixed in v4.2.0. + diff --git a/results/classifier/zero-shot/108/none/1847440 b/results/classifier/zero-shot/108/none/1847440 new file mode 100644 index 000000000..833444e9e --- /dev/null +++ b/results/classifier/zero-shot/108/none/1847440 @@ -0,0 +1,564 @@ +KVM: 0.100 +device: 0.089 +other: 0.073 +permissions: 0.066 +PID: 0.064 +semantic: 0.064 +boot: 0.063 +vnc: 0.061 +socket: 0.060 +files: 0.058 +debug: 0.058 +network: 0.055 +graphic: 0.054 +performance: 0.053 + +ppc64le: KVM guest fails to boot with an error `virtio_scsi: probe of virtio1 failed with error -22` on master + +PowerPC KVM Guest fails to boot on current qemu master(98b2e3c9ab3abfe476a2b02f8f51813edb90e72d), + +Env: +HW: IBM Power8 +Host Kernel: 5.4.0-rc2-00038-ge3280b54afed +Guest Kernel: 4.13.9-300.fc27.ppc64le +Qemu: https://github.com/qemu/qemu.git (master) +Libvirt: 5.4.0 + +Guest boot gets stuck: +... +[ OK ] Mounted Kernel Configuration File System. +[ 7.598740] virtio-pci 0000:00:01.0: enabling device (0000 -> 0003) +[ 7.598828] virtio-pci 0000:00:01.0: virtio_pci: leaving for legacy driver +[ 7.598957] virtio-pci 0000:00:02.0: enabling device (0000 -> 0003) +[ 7.599017] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver +[ 7.599123] virtio-pci 0000:00:04.0: enabling device (0000 -> 0003) +[ 7.599182] virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver +[ 7.620620] synth uevent: /devices/vio: failed to send uevent +[ 7.620624] vio vio: uevent: failed to send synthetic uevent +[ OK ] Started udev Coldplug all Devices. +[ 7.624559] audit: type=1130 audit(1570610300.990:5): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ OK ] Reached target System Initialization. +[ OK ] Reached target Basic System. +[ OK ] Reached target Remote File Systems (Pre). +[ OK ] Reached target Remote File Systems. +[ 7.642961] virtio_scsi: probe of virtio1 failed with error -22 +[ *** ] A start job is running for dev-disk…21b3519a80.device (14s / no limit) +... + + + +git bisect, yielded a bad commit [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm,client-architecture-support, reverting this commit boot the guest properly. + +git bisect start +# good: [9e06029aea3b2eca1d5261352e695edc1e7d7b8b] Update version for v4.1.0 release +git bisect good 9e06029aea3b2eca1d5261352e695edc1e7d7b8b +# bad: [98b2e3c9ab3abfe476a2b02f8f51813edb90e72d] Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging +git bisect bad 98b2e3c9ab3abfe476a2b02f8f51813edb90e72d +# good: [56e6250ede81b4e4b4ddb623874d6c3cdad4a96d] target/arm: Convert T16, nop hints +git bisect good 56e6250ede81b4e4b4ddb623874d6c3cdad4a96d +# good: [5d69cbdfdd5cd6dadc9f0c986899844a0e4de703] tests/tcg: target/s390x: Test MVC +git bisect good 5d69cbdfdd5cd6dadc9f0c986899844a0e4de703 +# good: [88112488cf228df8b7588c8aa38e16ecd0dff48e] qapi: Make check_type()'s array case a bit more obvious +git bisect good 88112488cf228df8b7588c8aa38e16ecd0dff48e +# good: [972bd57689f1e11311d86b290134ea2ed9c7c11e] ppc/kvm: Skip writing DPDES back when in run time state +git bisect good 972bd57689f1e11311d86b290134ea2ed9c7c11e +# bad: [1aba8716c8335e88b8c358002a6e1ac89f7dd258] ppc/pnv: Remove the XICSFabric Interface from the POWER9 machine +git bisect bad 1aba8716c8335e88b8c358002a6e1ac89f7dd258 +# bad: [00ed3da9b5c2e66e796a172df3e19545462b9c90] xics: Minor fixes for XICSFabric interface +git bisect bad 00ed3da9b5c2e66e796a172df3e19545462b9c90 +# good: [33432d7737b53c92791f90ece5dbe3b7bb1c79f5] target/ppc: introduce set_dfp{64,128}() helper functions +git bisect good 33432d7737b53c92791f90ece5dbe3b7bb1c79f5 +# good: [f6d4c423a222f02bfa84a49c3d306d7341ec9bab] target/ppc: remove unnecessary if() around calls to set_dfp{64,128}() in DFP macros +git bisect good f6d4c423a222f02bfa84a49c3d306d7341ec9bab +# bad: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm,client-architecture-support +git bisect bad e68cd0cb5cf49d334abe17231a1d2c28b846afa2 +# good: [c4ec08ab70bab90685d1443d6da47293e3aa312a] spapr-pci: Stop providing assigned-addresses +git bisect good c4ec08ab70bab90685d1443d6da47293e3aa312a +# first bad commit: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm,client-architecture-support + + +attached vmxml. + +qemu commandline: +/home/sath/qemu/ppc64-softmmu/qemu-system-ppc64 -name guest=vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-vm1/master-key.aes -machine pseries-4.2,accel=kvm,usb=off,dump-guest-core=off -m 81920 -overcommit mem-lock=off -smp 512,sockets=1,cores=128,threads=4 -uuid fd4a5d54-0216-490e-82d2-1d4e89683b3d -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=24,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/home/sath/tests/data/avocado-vt/images/jeos-27-ppc64le_vm1.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:df:24,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -M pseries,ic-mode=xics -msg timestamp=on + + + +On Thu, Oct 10, 2019 at 07:16:49AM -0000, Launchpad Bug Tracker wrote: +> You have been subscribed to a public bug by Satheesh Rajendran (sathnaga): +> +> PowerPC KVM Guest fails to boot on current qemu master, bad commit: +> e68cd0cb5cf49d334abe17231a1d2c28b846afa2 +> +> Env: +> HW: IBM Power9 +> Host Kernel: 5.4.0-rc2-00038-ge3280b54afed +> Guest Kernel: 4.13.9-300.fc27.ppc64le +> Qemu: https://github.com/qemu/qemu.git (master) +> Libvirt: 5.4.0 +> +> Guest boot gets stuck: +> ... +> [ OK ] Mounted Kernel Configuration File System. +> [ 7.598740] virtio-pci 0000:00:01.0: enabling device (0000 -> 0003) +> [ 7.598828] virtio-pci 0000:00:01.0: virtio_pci: leaving for legacy driver +> [ 7.598957] virtio-pci 0000:00:02.0: enabling device (0000 -> 0003) +> [ 7.599017] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver +> [ 7.599123] virtio-pci 0000:00:04.0: enabling device (0000 -> 0003) +> [ 7.599182] virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver +> [ 7.620620] synth uevent: /devices/vio: failed to send uevent +> [ 7.620624] vio vio: uevent: failed to send synthetic uevent +> [ OK ] Started udev Coldplug all Devices. +> [ 7.624559] audit: type=1130 audit(1570610300.990:5): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +> [ OK ] Reached target System Initialization. +> [ OK ] Reached target Basic System. +> [ OK ] Reached target Remote File Systems (Pre). +> [ OK ] Reached target Remote File Systems. +> [ 7.642961] virtio_scsi: probe of virtio1 failed with error -22 +> [ *** ] A start job is running for dev-disk…21b3519a80.device (14s / no limit) +> ... +> +> git bisect, yielded a bad commit +> [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm +> ,client-architecture-support, reverting this commit boot the guest +> properly. +> +> git bisect start +> # good: [9e06029aea3b2eca1d5261352e695edc1e7d7b8b] Update version for v4.1.0 release +> git bisect good 9e06029aea3b2eca1d5261352e695edc1e7d7b8b +> # bad: [98b2e3c9ab3abfe476a2b02f8f51813edb90e72d] Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging +> git bisect bad 98b2e3c9ab3abfe476a2b02f8f51813edb90e72d +> # good: [56e6250ede81b4e4b4ddb623874d6c3cdad4a96d] target/arm: Convert T16, nop hints +> git bisect good 56e6250ede81b4e4b4ddb623874d6c3cdad4a96d +> # good: [5d69cbdfdd5cd6dadc9f0c986899844a0e4de703] tests/tcg: target/s390x: Test MVC +> git bisect good 5d69cbdfdd5cd6dadc9f0c986899844a0e4de703 +> # good: [88112488cf228df8b7588c8aa38e16ecd0dff48e] qapi: Make check_type()'s array case a bit more obvious +> git bisect good 88112488cf228df8b7588c8aa38e16ecd0dff48e +> # good: [972bd57689f1e11311d86b290134ea2ed9c7c11e] ppc/kvm: Skip writing DPDES back when in run time state +> git bisect good 972bd57689f1e11311d86b290134ea2ed9c7c11e +> # bad: [1aba8716c8335e88b8c358002a6e1ac89f7dd258] ppc/pnv: Remove the XICSFabric Interface from the POWER9 machine +> git bisect bad 1aba8716c8335e88b8c358002a6e1ac89f7dd258 +> # bad: [00ed3da9b5c2e66e796a172df3e19545462b9c90] xics: Minor fixes for XICSFabric interface +> git bisect bad 00ed3da9b5c2e66e796a172df3e19545462b9c90 +> # good: [33432d7737b53c92791f90ece5dbe3b7bb1c79f5] target/ppc: introduce set_dfp{64,128}() helper functions +> git bisect good 33432d7737b53c92791f90ece5dbe3b7bb1c79f5 +> # good: [f6d4c423a222f02bfa84a49c3d306d7341ec9bab] target/ppc: remove unnecessary if() around calls to set_dfp{64,128}() in DFP macros +> git bisect good f6d4c423a222f02bfa84a49c3d306d7341ec9bab +> # bad: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm,client-architecture-support +> git bisect bad e68cd0cb5cf49d334abe17231a1d2c28b846afa2 +> # good: [c4ec08ab70bab90685d1443d6da47293e3aa312a] spapr-pci: Stop providing assigned-addresses +> git bisect good c4ec08ab70bab90685d1443d6da47293e3aa312a +> # first bad commit: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] +> spapr: Render full FDT on ibm,client-architecture-support + +Ah, dammit, I thought we'd fixed the problems with that patch :(. + +> +> attached vmxml. +> +> qemu commandline: +> /home/sath/qemu/ppc64-softmmu/qemu-system-ppc64 -name guest=vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-vm1/master-key.aes -machine pseries-4.2,accel=kvm,usb=off,dump-guest-core=off -m 81920 -overcommit mem-lock=off -smp 512,sockets=1,cores=128,threads=4 -uuid fd4a5d54-0216-490e-82d2-1d4e89683b3d -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=24,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/home/sath/tests/data/avocado-vt/images/jeos-27-ppc64le_vm1.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:df:24,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -M pseries,ic-mode=xics -msg timestamp=on +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: kvm powerpcm qemu + +-- +David Gibson | I'll have my music baroque, and my code +david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ + | _way_ _around_! +http://www.ozlabs.org/~dgibson + + +Ok, I just tried booting a guest with virtio-scsi and ic-mode=xics, and I wasn't able to reproduce this problem. + +Can you try simplifying your command line to see what options are needed to trigger this? + +Oh... are you using the SLOF (guest firmware) image included in the qemu tree, or is it coming from a separate package? + + +If it's from a separate package, that could be the problem - it needs to be updated before that qemu patch is safe. + + +Did try with the slof bin(-bios /usr/local/share/qemu/slof.bin) complied with qemu tree also, same issue persists, + + +/home/sath/qemu/ppc64-softmmu/qemu-system-ppc64 \ +-name guest=vm1,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-vm1/master-key.aes \ +-machine pseries-4.2,accel=kvm,usb=off,dump-guest-core=off \ +-bios /usr/local/share/qemu/slof.bin \ +-m 81920 \ +-overcommit mem-lock=off \ +-smp 512,sockets=1,cores=128,threads=4 \ +-uuid fd4a5d54-0216-490e-82d2-1d4e89683b3d \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=24,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device qemu-xhci,id=usb,bus=pci.0,addr=0x3 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 \ +-drive file=/home/sath/tests/data/avocado-vt/images/jeos-27-ppc64le_vm1.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:df:24,bus=pci.0,addr=0x1 \ +-chardev pty,id=charserial0 \ +-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ +-M pseries,ic-mode=dual \ +-msg timestamp=on + + +Did try with xics aswell, same issue. + +Host HW: + +#lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 128 +On-line CPU(s) list: 0-127 +Thread(s) per core: 4 +Core(s) per socket: 16 +Socket(s): 2 +NUMA node(s): 2 +Model: 2.3 (pvr 004e 1203) +Model name: POWER9, altivec supported +CPU max MHz: 3800.0000 +CPU min MHz: 2300.0000 +L1d cache: 32K +L1i cache: 32K +L2 cache: 512K +L3 cache: 10240K +NUMA node0 CPU(s): 0-63 +NUMA node8 CPU(s): 64-127 + + +FW: skiboot-v6.3.2 + +Regards, +-Satheesh + +Please provide the entire guest booting output, from slof till it is stuck. +Also please try with -smp 1. Thanks. + +Domain vm1 started +Connected to domain vm1 +Escape character is ^] +Populating /vdevice methods +Populating /vdevice/vty@30000000 +Populating /vdevice/nvram@71000000 +Populating /pci@800000020000000 + 00 0800 (D) : 1af4 1000 virtio [ net ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" + 00 1800 (D) : 1b36 000d serial bus [ usb-xhci ] + 00 2000 (D) : 1af4 1002 unknown-legacy-device* +No NVRAM common partition, re-initializing... +Scanning USB + XHCI: Initializing +Using default console: /vdevice/vty@30000000 + + 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: from: /pci@800000020000000/scsi@2/disk@100000000000000 ... Successfully loaded + + +OF stdout device is: /vdevice/vty@30000000 +Preparing to boot Linux version 4.13.9-300.fc27.ppc64le (<email address hidden>) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #1 SMP Mon Oct 23 13:28:27 UTC 2017 +Detected machine type: 0000000000000101 +command line: BOOT_IMAGE=/boot/vmlinuz-4.13.9-300.fc27.ppc64le root=UUID=500d2159-c568-459e-8864-1c21b3519a80 ro console=tty0 console=ttyS0,115200 console=hvc0 +Max number of cores passed to firmware: 1024 (NR_CPUS = 1024) +Calling ibm,client-architecture-support...Node not supported +Node not supported + not implemented +memory layout at init: + memory_limit : 0000000000000000 (16 MB aligned) + alloc_bottom : 00000000046a0000 + alloc_top : 0000000010000000 + alloc_top_hi : 0000001400000000 + rmo_top : 0000000010000000 + ram_top : 0000001400000000 +instantiating rtas at 0x000000000daf0000... done +prom_hold_cpus: skipped +copying OF device tree... +Building dt strings... +Building dt structure... +Device tree strings 0x00000000046b0000 -> 0x00000000046b0b3f +Device tree struct 0x00000000046c0000 -> 0x00000000046d0000 +Quiescing Open Firmware ... +Booting Linux via __start() @ 0x0000000002000000 ... +[ 0.000000] Page sizes from device-tree: +[ 0.000000] Page size shift = 12 AP=0x0 +[ 0.000000] Page size shift = 16 AP=0x5 +[ 0.000000] Page size shift = 21 AP=0x1 +[ 0.000000] Page size shift = 30 AP=0x2 +[ 0.000000] Using radix MMU under hypervisor +[ 0.000000] Mapped range 0x0 - 0x1400000000 with 0x40000000 +[ 0.000000] Process table c0000013ff000000 and radix root for kernel: c0000000014c0000 +[ 0.000000] Linux version 4.13.9-300.fc27.ppc64le (<email address hidden>) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #1 SMP Mon Oct 23 13:28:27 UTC 2017 +[ 0.000000] Found initrd at 0xc000000003900000:0xc0000000046967f5 +[ 0.000000] Using pSeries machine description +[ 0.000000] bootconsole [udbg0] enabled +[ 0.000000] Partition configured for 2 cpus. +[ 0.000000] CPU maps initialized for 1 thread per core + -> smp_release_cpus() +spinning_secondaries = 1 + <- smp_release_cpus() +[ 0.000000] ----------------------------------------------------- +[ 0.000000] ppc64_pft_size = 0x0 +[ 0.000000] phys_mem_size = 0x1400000000 +[ 0.000000] dcache_bsize = 0x80 +[ 0.000000] icache_bsize = 0x80 +[ 0.000000] cpu_features = 0x075c7a7c18500249 +[ 0.000000] possible = 0x5fffffff18500649 +[ 0.000000] always = 0x0000000018100040 +[ 0.000000] cpu_user_features = 0xdc0065c2 0xaee00000 +[ 0.000000] mmu_features = 0x3c006041 +[ 0.000000] firmware_features = 0x00000001455a445f +[ 0.000000] ----------------------------------------------------- +[ 0.000000] numa: NODE_DATA [mem 0x13fffe7e80-0x13ffff1b7f] +[ 0.000000] PCI host bridge /pci@800000020000000 ranges: +[ 0.000000] IO 0x0000200000000000..0x000020000000ffff -> 0x0000000000000000 +[ 0.000000] MEM 0x0000200080000000..0x00002000ffffffff -> 0x0000000080000000 +[ 0.000000] MEM 0x0000210000000000..0x000021ffffffffff -> 0x0000210000000000 +[ 0.000000] OF: PCI: PROBE_ONLY disabled +[ 0.000000] PPC64 nvram contains 65536 bytes +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000000000-0x00000013ffffffff] +[ 0.000000] DMA32 empty +[ 0.000000] Normal empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000000000-0x00000013ffffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000013ffffffff] +[ 0.000000] percpu: Embedded 3 pages/cpu @c0000013fef80000 s151064 r0 d45544 u196608 +[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 1309440 +[ 0.000000] Policy zone: DMA +[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.13.9-300.fc27.ppc64le root=UUID=500d2159-c568-459e-8864-1c21b3519a80 ro console=tty0 console=ttyS0,115200 console=hvc0 +[ 0.000000] PID hash table entries: 4096 (order: -1, 32768 bytes) +[ 0.000000] Memory: 83754240K/83886080K available (11968K kernel code, 1792K rwdata, 3136K rodata, 4288K init, 2405K bss, 131840K reserved, 0K cma-reserved) +[ 0.000000] random: get_random_u64 called from cache_random_seq_create+0xa0/0x180 with crng_init=0 +[ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 +[ 0.000000] ftrace: allocating 29419 entries in 11 pages +[ 0.000000] Hierarchical RCU implementation. +[ 0.000000] RCU restricting CPUs from NR_CPUS=1024 to nr_cpu_ids=2. +[ 0.000000] Tasks RCU enabled. +[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 +[ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 +[ 0.000000] time_init: 56 bit decrementer (max: 7fffffffffffff) +[ 0.000483] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x761537d007, max_idle_ns: 440795202126 ns +[ 0.001327] clocksource: timebase mult[1f40000] shift[24] registered +[ 0.001868] Console: colour dummy device 80x25 +[ 0.002310] console [tty0] enabled +[ 0.002588] console [hvc0] enabled +[ 0.002588] console [hvc0] enabled +[ 0.002890] bootconsole [udbg0] disabled +[ 0.002890] bootconsole [udbg0] disabled +[ 0.003238] pid_max: default: 32768 minimum: 301 +[ 0.003336] Security Framework initialized +[ 0.003361] Yama: becoming mindful. +[ 0.003387] SELinux: Initializing. +[ 0.008989] Dentry cache hash table entries: 8388608 (order: 10, 67108864 bytes) +[ 0.011926] Inode-cache hash table entries: 4194304 (order: 9, 33554432 bytes) +[ 0.012030] Mount-cache hash table entries: 131072 (order: 4, 1048576 bytes) +[ 0.012237] Mountpoint-cache hash table entries: 131072 (order: 4, 1048576 bytes) +[ 0.012576] EEH: pSeries platform initialized +[ 0.012611] POWER9 performance monitor hardware support registered +[ 0.012664] Hierarchical SRCU implementation. +[ 0.013001] smp: Bringing up secondary CPUs ... +[ 0.015623] smp: Brought up 1 node, 2 CPUs +[ 0.015662] numa: Node 0 CPUs: 0-1 +[ 0.019886] devtmpfs: initialized +[ 0.024963] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 0.025027] futex hash table entries: 512 (order: 0, 65536 bytes) +[ 0.025177] NET: Registered protocol family 16 +[ 0.027932] EEH: No capable adapters found +[ 0.030363] cpuidle: using governor menu +[ 0.031979] pstore: using zlib compression +[ 0.032005] pstore: Registered nvram as persistent store backend +Linux ppc64le +#1 SMP Mon Oct 2[ 0.035136] PCI: Probing PCI hardware +[ 0.035185] PCI host bridge to bus 0000:00 +[ 0.035210] pci_bus 0000:00: root bus resource [io 0x10000-0x1ffff] (bus address [0x0000-0xffff]) +[ 0.035260] pci_bus 0000:00: root bus resource [mem 0x200080000000-0x2000ffffffff] (bus address [0x80000000-0xffffffff]) +[ 0.035318] pci_bus 0000:00: root bus resource [mem 0x210000000000-0x21ffffffffff] +[ 0.035360] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.037044] IOMMU table initialized, virtual merging enabled +[ 0.037088] iommu: Adding device 0000:00:01.0 to group 0, default domain type -1 +[ 0.037145] pci 0000:00:01.0: of_irq_parse_pci: failed with rc=134 +[ 0.037190] iommu: Adding device 0000:00:02.0 to group 0, default domain type -1 +[ 0.037242] pci 0000:00:02.0: of_irq_parse_pci: failed with rc=134 +[ 0.037286] iommu: Adding device 0000:00:03.0 to group 0, default domain type -1 +[ 0.037337] pci 0000:00:03.0: of_irq_parse_pci: failed with rc=134 +[ 0.037380] iommu: Adding device 0000:00:04.0 to group 0, default domain type -1 +[ 0.037442] pci 0000:00:04.0: of_irq_parse_pci: failed with rc=134 +[ 0.043219] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.043275] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages +[ 0.051951] vgaarb: loaded +[ 0.052021] SCSI subsystem initialized +[ 0.054039] usbcore: registered new interface driver usbfs +[ 0.054076] usbcore: registered new interface driver hub +[ 0.054113] usbcore: registered new device driver usb +[ 0.055226] EDAC MC: Ver: 3.0.0 +[ 0.060393] NetLabel: Initializing +[ 0.060419] NetLabel: domain hash size = 128 +[ 0.060447] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 0.060492] NetLabel: unlabeled traffic allowed by default +[ 0.062836] clocksource: Switched to clocksource timebase +[ 0.073228] VFS: Disk quotas dquot_6.6.0 +[ 0.073275] VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) +[ 0.318455] NET: Registered protocol family 2 +[ 0.318612] TCP established hash table entries: 524288 (order: 6, 4194304 bytes) +[ 0.319695] TCP bind hash table entries: 65536 (order: 4, 1048576 bytes) +[ 0.319940] TCP: Hash tables configured (established 524288 bind 65536) +[ 0.320000] UDP hash table entries: 65536 (order: 5, 2097152 bytes) +[ 0.320342] UDP-Lite hash table entries: 65536 (order: 5, 2097152 bytes) +[ 0.320713] NET: Registered protocol family 1 +[ 0.320782] pci 0000:00:03.0: enabling device (0000 -> 0002) +[ 0.320897] Unpacking initramfs... +[ 0.536932] Freeing initrd memory: 13888K +[ 0.540445] rtas_flash: no firmware flash support +[ 0.540685] audit: initializing netlink subsys (disabled) +[ 0.544654] Initialise system trusted keyrings +[ 0.544693] Key type blacklist registered +[ 0.545355] audit: type=2000 audit(1571635628.541:1): state=initialized audit_enabled=0 res=1 +[ 0.547068] workingset: timestamp_bits=38 max_order=21 bucket_order=0 +[ 0.548074] zbud: loaded +[ 0.693638] random: fast init done +[ 0.756362] NET: Registered protocol family 38 +[ 0.756416] Key type asymmetric registered +[ 0.756450] Asymmetric key parser 'x509' registered +[ 0.756535] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250) +[ 0.757780] io scheduler noop registered +[ 0.757818] io scheduler deadline registered +[ 0.757900] io scheduler cfq registered (default) +[ 0.757944] io scheduler mq-deadline registered +[ 0.758947] atomic64_test: passed +[ 0.773254] libphy: Fixed MDIO Bus: probed +[ 0.775507] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 0.775573] ehci-pci: EHCI PCI platform driver +[ 0.775625] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 0.775685] ohci-pci: OHCI PCI platform driver +[ 0.775734] uhci_hcd: USB Universal Host Controller Interface driver +[ 0.775841] xhci_hcd 0000:00:03.0: enabling device (0000 -> 0002) +[ 0.775953] xhci_hcd 0000:00:03.0: xHCI Host Controller +[ 0.777192] xhci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 1 +[ 0.777541] xhci_hcd 0000:00:03.0: ibm,query-pe-dma-windows(2026) 1800 2000 0 returned -3 +[ 0.778091] xhci_hcd 0000:00:03.0: hcc params 0x00087001 hci version 0x100 quirks 0x00000010 +[ 0.778169] xhci_hcd 0000:00:03.0: No msi-x/msi found and no IRQ in BIOS +[ 0.778223] xhci_hcd 0000:00:03.0: startup error -22 +[ 0.778268] xhci_hcd 0000:00:03.0: USB bus 1 deregistered +[ 0.780041] xhci_hcd 0000:00:03.0: init 0000:00:03.0 fail, -22 +[ 0.780101] xhci_hcd: probe of 0000:00:03.0 failed with error -22 +[ 0.780174] usbcore: registered new interface driver usbserial +[ 0.780233] usbcore: registered new interface driver usbserial_generic +[ 0.780291] usbserial: USB Serial support registered for generic +[ 0.782554] mousedev: PS/2 mouse device common for all mice +[ 0.782886] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0 +[ 0.783012] device-mapper: uevent: version 1.0.3 +[ 0.784846] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: <email address hidden> +[ 0.786176] hidraw: raw HID events driver (C) Jiri Kosina +[ 0.786257] usbcore: registered new interface driver usbhid +[ 0.786300] usbhid: USB HID core driver +[ 0.786388] drop_monitor: Initializing network drop monitor service +[ 0.786511] ip_tables: (C) 2000-2006 Netfilter Core Team +[ 0.786564] Initializing XFRM netlink socket +[ 0.786734] NET: Registered protocol family 10 +[ 0.794930] Segment Routing with IPv6 +[ 0.794983] mip6: Mobile IPv6 +[ 0.795015] NET: Registered protocol family 17 +[ 0.800017] registered taskstats version 1 +[ 0.800060] Loading compiled-in X.509 certificates +[ 0.850282] Loaded X.509 cert 'Fedora kernel signing key: a878db2990f3e3239cc963ffd6fea115d9415954' +[ 0.850347] zswap: loaded using pool lzo/zbud +[ 0.857402] Key type big_key registered +[ 0.864367] Key type encrypted registered +[ 0.865572] rtc-generic rtc-generic: setting system clock to 2019-10-21 05:27:08 UTC (1571635628) +[ 0.866653] Freeing unused kernel memory: 4288K +[ 0.866684] This architecture does not have kernel memory protection. +[ 0.872683] systemd[1]: systemd 234 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN default-hierarchy=hybrid) +[ 0.872817] systemd[1]: Detected virtualization kvm. +[ 0.872855] systemd[1]: Detected architecture ppc64-le. +[ 0.872885] systemd[1]: Running in initial RAM disk. + +Welcome to Fedora 27 (Twenty Seven) dracut-046-5.fc27 (Initramfs)! + +[ 0.873073] systemd[1]: Set hostname to <atest-guest>. +[ 0.952006] systemd[1]: Listening on Journal Audit Socket. +[ OK ] Listening on Journal Audit Socket. +[ 0.952292] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. +[ OK ] Started Dispatch Password Requests to Console Directory Watch. +[ 0.952488] systemd[1]: Reached target Paths. +[ OK ] Reached target Paths. +[ 0.952639] systemd[1]: Reached target Local File Systems. +[ OK ] Reached target Local File Systems. +[ 0.952816] systemd[1]: Reached target Timers. +[ OK ] Reached target Timers. +[ OK ] Listening on Journal Socket (/dev/log). +[ OK ] Listening on Journal Socket. +[ OK ] Reached target Swap. +[ OK ] Listening on udev Control Socket. +[ OK ] Listening on udev Kernel Socket. +[ OK ] Reached target Sockets. +[ OK ] Created slice System Slice. + Starting Create Volatile Files and Directories... + Starting Create list of required st…ce nodes for the current kernel... +[ OK ] Reached target Slices. + Starting Journal Service... + Starting Apply Kernel Variables... +[ OK ] Started Create Volatile Files and Directories. +[ OK ] Started Apply Kernel Variables. +[ OK ] Started Create list of required sta…vice nodes for the current kernel. + Starting Create Static Device Nodes in /dev... +[ OK ] Started Create Static Device Nodes in /dev. +[ 0.967752] audit: type=1130 audit(1571635628.603:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-tmpfiles-setup-dev comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' + Starting udev Kernel Device Manager... +[ OK ] Started Journal Service. +[ 0.973468] audit: type=1130 audit(1571635628.608:3): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ OK ] Started udev Kernel Device Manager. + Starting udev Coldplug all Devices... +[ 0.975851] audit: type=1130 audit(1571635628.610:4): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' + Mounting Kernel Configuration File System... +[ OK ] Mounted Kernel Configuration File System. +[ 1.039675] virtio-pci 0000:00:01.0: enabling device (0000 -> 0003) +[ 1.039749] virtio-pci 0000:00:01.0: virtio_pci: leaving for legacy driver +[ 1.041139] synth uevent: /devices/vio: failed to send uevent +[ 1.041140] vio vio: uevent: failed to send synthetic uevent +[ OK ] Started udev Coldplug all Devices. +[ 1.042946] audit: type=1130 [audit(1571635628 OK id=1 umid=0 auid=429496] Reached target R7295 ses=4294967e295 subj=kernel mote File Systemmsg='unit=systemsd-udev-trigger c (Pre).omm="systemd" ex +e="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 1.043884] virtio-pci 0000:00:02.0: enabling device (0000 -> 0003) +[ 1.043908] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver +[ 1.043979] virtio-pci 0000:00:04.0: enabling device (0000 -> 0003) +[ 1.044003] virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver +[ OK ] Reached target Remote File Systems. +[ OK ] Reached target System Initialization. +[ OK ] Reached target Basic System. +[ 1.102715] virtio_scsi: probe of virtio1 failed with error -22 +[** ] A start job is running for dev-disk…19a80.device (1min 50s / no limit) + + +Same observation with smp 1 even. + +https://patchwork.ozlabs.org/patch/1180363/ should fix it, a SLOF update for QEMU is also posted +https://github.com/aik/qemu/tree/qemu-slof-20191022-branch + +The SLOF fix has been merged 1.5 years ago, so I assume this can be marked as fixed now. + diff --git a/results/classifier/zero-shot/108/none/1847467 b/results/classifier/zero-shot/108/none/1847467 new file mode 100644 index 000000000..8c7e73239 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1847467 @@ -0,0 +1,58 @@ +device: 0.207 +performance: 0.187 +network: 0.170 +graphic: 0.155 +semantic: 0.143 +vnc: 0.128 +other: 0.111 +PID: 0.108 +permissions: 0.103 +socket: 0.102 +boot: 0.094 +KVM: 0.089 +debug: 0.082 +files: 0.059 + +qemu-x86_64 segment prefixes error + +qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) + +In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. + +example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). + + +I attach a small C++ program that shows this discrepancy. + +$ ./sample +I'm not in QEMU + +$ qemu-x86_64 ./sample +I'm in 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 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. + + +Repro case in comment #1 still demonstrates bug. + + + +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/267 + + diff --git a/results/classifier/zero-shot/108/none/1848231 b/results/classifier/zero-shot/108/none/1848231 new file mode 100644 index 000000000..711474b0c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1848231 @@ -0,0 +1,43 @@ +semantic: 0.583 +device: 0.455 +graphic: 0.370 +other: 0.323 +socket: 0.196 +performance: 0.115 +network: 0.109 +vnc: 0.091 +permissions: 0.070 +boot: 0.066 +KVM: 0.062 +debug: 0.041 +PID: 0.038 +files: 0.008 + +serial/parallel character devices created for the none-machine + +The none-machine can not be started unless using "-serial null": + +qemu-system-x86_64 -machine none -nographic -monitor stdio +QEMU 3.1.1 monitor - type 'help' for more information +(qemu) qemu-system-x86_64: cannot use stdio by multiple character devices +qemu-system-x86_64: could not connect serial device to character backend 'stdio' +$ + +$ qemu-system-mips -machine none -nographic -serial null -monitor stdio +QEMU 4.1.50 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +compat_monitor0: filename=stdio +serial0: filename=null +(qemu) + +You can start 'none' without "-serial null". Examples: + +qemu-system-x86_64 -machine none +qemu-system-x86_64 -machine none -monitor stdio +qemu-system-x86_64 -machine none -nographic +qemu-system-x86_64 -machine none -monitor stdio -display none + +Your command line "qemu-system-x86_64 -machine none -nographic -monitor stdio" fails because "-nographic" says "please create a serial port using stdio" but "-monitor stdio" tries to use stdio for something else. You get the same message for any machine (eg "pc"), not just "none". If what you wanted was "just don't create the graphical display" that's "-display none" -- "-nographic" is a collection of things including both 'no display' and also 'default to creating a serial device to stdio' and 'default to creating a monitor muxed with that serial'. + + diff --git a/results/classifier/zero-shot/108/none/1848556 b/results/classifier/zero-shot/108/none/1848556 new file mode 100644 index 000000000..3a3064aba --- /dev/null +++ b/results/classifier/zero-shot/108/none/1848556 @@ -0,0 +1,240 @@ +semantic: 0.373 +graphic: 0.341 +device: 0.301 +PID: 0.273 +debug: 0.260 +permissions: 0.235 +performance: 0.231 +other: 0.194 +network: 0.181 +boot: 0.163 +vnc: 0.150 +KVM: 0.135 +socket: 0.126 +files: 0.123 + +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/zero-shot/108/none/1849894 b/results/classifier/zero-shot/108/none/1849894 new file mode 100644 index 000000000..38cd4c643 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1849894 @@ -0,0 +1,87 @@ +other: 0.472 +permissions: 0.374 +KVM: 0.371 +PID: 0.363 +device: 0.344 +vnc: 0.343 +performance: 0.338 +socket: 0.336 +network: 0.331 +semantic: 0.329 +graphic: 0.327 +files: 0.321 +debug: 0.296 +boot: 0.285 + +hw/scsi/scsi-disk.c line 2554 allocation overflow + +When compiling qemu from git master (at commit 03bf012e523ecdf047ac56b2057950247256064d ) on Linux amd64, with gcc-9 9.2.1 , and using `-march=native -flto`, during linking of most target binaries, compiler does detect an issue with allocation in scsi_disk_new_request_dump and aborts compilation. + + +make[1]: Entering directory '/home/user/qemu/slirp' +make[1]: Nothing to be done for 'all'. +make[1]: Leaving directory '/home/user/qemu/slirp' +nm: stats64.o: no symbols + LINK aarch64-softmmu/qemu-system-aarch64 +In function ‘scsi_disk_new_request_dump’, + inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2580:9, + inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2564:21: +hw/scsi/scsi-disk.c:2554:19: error: argument 1 value ‘18446744073709551612’ exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] +hw/scsi/scsi-disk.c: In function ‘scsi_new_request’: +/usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation function ‘g_malloc’ declared here + 78 | gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE(1); + | ^ +lto1: all warnings being treated as errors +lto-wrapper: fatal error: c++ returned 1 exit status +compilation terminated. +/usr/bin/ld: error: lto-wrapper failed +collect2: error: ld returned 1 exit status + + + +same happens for most other targets: alpha-softmmu/qemu-system-alpha arm-softmmu/qemu-system-arm hppa-softmmu/qemu-system-hppa i386-softmmu/qemu-system-i386 lm32-softmmu/qemu-system-lm32 mips-softmmu/qemu-system-mips mips64-softmmu/qemu-system-mips64 mips64el-softmmu/qemu-system-mips64el mipsel-softmmu/qemu-system-mipsel ppc-softmmu/qemu-system-ppc ppc64-softmmu/qemu-system-ppc64 riscv32-softmmu/qemu-system-riscv32 riscv64-softmmu/qemu-system-riscv64 s390x-softmmu/qemu-system-s390x sh4-softmmu/qemu-system-sh4 sh4eb-softmmu/qemu-system-sh4eb sparc-softmmu/qemu-system-sparc sparc64-softmmu/qemu-system-sparc64 x86_64-softmmu/qemu-system-x86_64 xtensa-softmmu/qemu-system-xtensa xtensaeb-softmmu/qemu-system-xtensaeb + +Notice -softmmu being a common factor here. + + + +The size of the allocation for the temporary buffer for dumping using snprintf is determined based on the size of the buffer via call to scsi_cdb_length. I believe the heavy inlining and constant propagation makes scsi_cdb_length return -1, so len = -1. Then allocation size is 5*len + 1, or -4. Which overflows to 2^64 - 4 or so. + +The case of len==-1 from scsi_cdb_length happens if the (buf[0] >> 5) is not 0, 1, 2, 4 or 5. + +However, I can't find out how gcc figures out that buf[0] is not one of these variables. To me looking at this function, compiler should not know anything about buf[0]. + +I tried following the chain of calls back, including devirtualize alloc_req, and I found scsi_device_alloc_req calling these alloc_req callbacks, but it is itself called from scsi_req_new, which is called in get_scsi_requests , just after buf is filled from QEMUFile using qemu_get_buffer, which ultimately goes even further into read paths, which there might be many AFAIK. + + + + +glib2 version 2.62.1-1 + +FYI. Adding if (len <= 0) return; in the scsi_disk_new_request_dump solved the compilation issue for me. + +So indeed gcc thinks len == -1 + +I am pretty sure the build qemu is functional, as this path is only taken if the trace_event_get_state_backends(TRACE_SCSI_DISK_NEW_REQUEST) is true, which by default it is not. + +BTW. Also, aarch64-softmmu/qemu-system-aarch64 takes very long time to link compared to other targets, so I recommend using -flto=16 to increase parallelism, and reduce lto link time to about 4 minutes. (But 64GB of memory recommended). + +I also tested with --disable-slirp configure flag. Still same issue. + +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. + + +Likely not happening anymore since commit e91bae8e98a ("scsi: Silence gcc warning"). + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/185 b/results/classifier/zero-shot/108/none/185 new file mode 100644 index 000000000..bab3cafca --- /dev/null +++ b/results/classifier/zero-shot/108/none/185 @@ -0,0 +1,16 @@ +semantic: 0.381 +boot: 0.300 +debug: 0.284 +performance: 0.273 +graphic: 0.244 +KVM: 0.154 +vnc: 0.142 +network: 0.115 +device: 0.062 +PID: 0.021 +permissions: 0.008 +other: 0.002 +socket: 0.001 +files: 0.000 + +Coroutines: Audit use of "coroutine_fn" specifier diff --git a/results/classifier/zero-shot/108/none/1851552 b/results/classifier/zero-shot/108/none/1851552 new file mode 100644 index 000000000..4b0309a21 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1851552 @@ -0,0 +1,334 @@ +graphic: 0.306 +network: 0.297 +PID: 0.295 +other: 0.291 +performance: 0.290 +permissions: 0.288 +boot: 0.284 +semantic: 0.268 +debug: 0.256 +device: 0.255 +files: 0.225 +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/zero-shot/108/none/1854204 b/results/classifier/zero-shot/108/none/1854204 new file mode 100644 index 000000000..adf31ade3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1854204 @@ -0,0 +1,67 @@ +device: 0.465 +graphic: 0.373 +other: 0.347 +semantic: 0.314 +socket: 0.250 +performance: 0.216 +debug: 0.197 +permissions: 0.184 +boot: 0.171 +vnc: 0.151 +files: 0.149 +PID: 0.148 +network: 0.144 +KVM: 0.066 + +Menu is not clickable on OSX Catalina + +1) Run `qemu-system-x86_64` +2) Try to click on the main menu + +Menu is not clickable until another window is activated and QEMU window is activated again + +Does this reproduce on earlier pre-Catalina OSX versions, or is it Catalina-specific? + +This is probably not going to be addressed unless somebody wants to investigate and write a patch for it -- OSX support in QEMU is only very barely maintained. + + +Catalina-specific. It also affects several UI toolkits. This workaround https://stackoverflow.com/a/7602677 seems to help. + +Thanks for the research. That looks like an OSX bug to me -- the simple two-line set of operations to do this that previously worked now needs some horribly complicated multi-stage sequence, and the first suggested workaround is doing something strange involving the Finder and a 0.1 second delay which I am definitely suspicious of. Apple should fix their OS to stop breaking applications :-) + +The second suggested approach is essentially to add: + + SetSystemUIMode(kUIModeNormal, 0); + [NSApp activateIgnoringOtherApps:YES]; + +which for us probably would want to go before the [NSApp run] (or at least after we've created the sharedApplication). + +It's a bit odd also that the stackoverflow question says this only happens "if you don't call [TransformProcessType] early enough", because QEMU calls that about as early as it is feasibly possible to do, very near the top of main() in cocoa.m. + + +The workaround on SO was posted way back in 2011. It has initially solved a different issue, I think. + +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. + + +Still a bug. + + + +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/225 + + diff --git a/results/classifier/zero-shot/108/none/1855002 b/results/classifier/zero-shot/108/none/1855002 new file mode 100644 index 000000000..d6220537f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1855002 @@ -0,0 +1,49 @@ +device: 0.578 +graphic: 0.453 +socket: 0.367 +performance: 0.365 +other: 0.304 +vnc: 0.239 +boot: 0.239 +PID: 0.231 +permissions: 0.227 +network: 0.212 +debug: 0.212 +files: 0.151 +semantic: 0.121 +KVM: 0.028 + +Cannot boot arm kernel images on s390x + +While running the acceptance tests on s390x, the arm tests under qemu/tests/acceptance/boot_linux_console.py will timeout, except the test using u-boot. All the arm tests run without problems on x86 and ppc. + +This test boots the kernel and wait for a kernel panic to make sure it can boot that kind of kernel on the host running the test. The URL for the kernels are available inside the python test code, but I'm listing them here: + +Fail: https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/armhfp/os/images/pxeboot/vmlinuz +Fail: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb +Fail: https://snapshot.debian.org/archive/debian/20190928T224601Z/pool/main/l/linux/linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb +Pass: https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test-binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/spi.bin + +I tried to manually investigate the problem with the first kernel of the list. The command I used to try to boot it was: + +/home/linux1/src/v4.2.0-rc3/bin/qemu-system-arm -serial stdio -machine virt -kernel /home/linux1/venv/python3/data/cache/by_location/1d5fdf8018e79b806aa982600c0866b199946efc/vmlinuz +-append "printk.time=0 console=ttyAMA0" + +On an x86 machine, I can see it boots and ends with a kernel panic as expected. On s390x, it just hangs. + +I also tried to debug with gdb, redirecting the monitor and the serial console to other terminal sessions without success. + +QEMU version is the latest as of today,tag v4.2.0-rc4, commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e. + +s390x system is a Red Hat Enterprise Linux Server 7.7 running as a z/VM 6.4.0 guest at IBM LinuxONE Community Cloud. + +x86 system is a Fedora 31 running on Intel i7-8650U. + + +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/187 + + diff --git a/results/classifier/zero-shot/108/none/1855617 b/results/classifier/zero-shot/108/none/1855617 new file mode 100644 index 000000000..8269d7518 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1855617 @@ -0,0 +1,76 @@ +other: 0.529 +graphic: 0.526 +PID: 0.500 +device: 0.495 +permissions: 0.484 +network: 0.481 +performance: 0.442 +semantic: 0.442 +vnc: 0.442 +KVM: 0.435 +files: 0.418 +socket: 0.380 +boot: 0.366 +debug: 0.318 + +savevm with hax saves wrong register state + +I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. + +cc'ing Colin and Yu for Hax info: + +* Alex (<email address hidden>) wrote: +> Public bug reported: +> +> I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +> When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. +> +> ** 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/1855617 +> +> Title: +> savevm with hax saves wrong register state +> +> Status in QEMU: +> New +> +> Bug description: +> I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +> When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1855617/+subscriptions +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + + +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/188 + + diff --git a/results/classifier/zero-shot/108/none/1856399 b/results/classifier/zero-shot/108/none/1856399 new file mode 100644 index 000000000..c5393266c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1856399 @@ -0,0 +1,61 @@ +other: 0.454 +device: 0.411 +semantic: 0.295 +graphic: 0.288 +KVM: 0.275 +performance: 0.243 +network: 0.237 +PID: 0.198 +permissions: 0.185 +socket: 0.185 +boot: 0.158 +files: 0.158 +vnc: 0.140 +debug: 0.124 + +Intel GVT-g works in X11, segfaults in wayland + +Hello, + +I am using an uptodate Arch Linux 64bit with qemu version 4.2.0, but the problem was also present in older versions. The problem occurs with Linux 5.4 and 4.19. +The problem also occurs with Debian as guest. I am running sway. +If I provide -vga std, then qemu works fine until I use the qemu window to switch to the vfio-pci device. There are no problems under X11/xwayland at all. + + +Commandline: +qemu-system-x86_64 + -enable-kvm + -cpu host + -smp 2 + -m 8192 + -display gtk,gl=on + -device vfio-pci,sysfsdev=/sys/devices/pci0000:00/0000:00:02.0/[ID]/,x-igd-opregion=on,display=on + -cdrom archlinux-2019.11.01-x86_64.iso + -vga none + +Forgot to mention, the crash is a segfault. +If there is more information needed, I am happy to provide it. + +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. + + +Still present on qemu 5.2.0 and Linux 5.10 + + +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/189 + + diff --git a/results/classifier/zero-shot/108/none/186 b/results/classifier/zero-shot/108/none/186 new file mode 100644 index 000000000..1f57aae06 --- /dev/null +++ b/results/classifier/zero-shot/108/none/186 @@ -0,0 +1,16 @@ +semantic: 0.235 +device: 0.204 +permissions: 0.204 +boot: 0.200 +KVM: 0.159 +socket: 0.151 +PID: 0.142 +vnc: 0.111 +performance: 0.101 +network: 0.083 +debug: 0.056 +other: 0.051 +graphic: 0.024 +files: 0.019 + +Audit consistent option usage in documentation diff --git a/results/classifier/zero-shot/108/none/1860053 b/results/classifier/zero-shot/108/none/1860053 new file mode 100644 index 000000000..14550ad36 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1860053 @@ -0,0 +1,74 @@ +device: 0.445 +performance: 0.371 +socket: 0.298 +debug: 0.287 +network: 0.277 +other: 0.274 +permissions: 0.253 +graphic: 0.252 +PID: 0.238 +semantic: 0.211 +boot: 0.185 +files: 0.155 +vnc: 0.107 +KVM: 0.091 + +Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le + +Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2 image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-ci.org. + +From golang's https://github.com/golang/go/issues/36592: + +It was discovered that golang's time.NewTicker() and time.Sleep() malfunction when a compiled application was run via QEMU's ppc64le emulator in user mode. + +The methods did not malfunction on actual PowerPC hardware or when the same golang application was compiled for golang's arm, arm64 or 386 targets and was run via user mode QEMU on the same system. + +Curiously, the methods also worked when the program was compiled under go 1.11, but do malfunction in go 1.12 and 1.13. + +It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E: +https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b + +We therefore suspect there may be a bug in QEMU's user-mode emulation of ppc64le as relates to vDSO calls to clock_gettime(). + +The nature of the malfunction of time.NewTicker() and time.Sleep() is such that sleeps or ticks with a granularity of less than one second do not appear to be possible (they all revert to 1 second sleeps/ticks). Could it be that the nanoseconds field of clock_gettime() is getting lost in the vDSO version but not in the syscall? Or some other issue calling these methods via vDSO? + +Thanks in advance. + +QEMU does not implement any vDSO, so this cannot be the explanation. + +Since there is no vdso, the Go code goes into the syscall fallback: + +MOVD runtime·vdsoClockgettimeSym(SB), R12 // Check for VDSO availability +CMP R12, R0 +BEQ fallback +(...) +fallback: + ADD $32, R1, R4 + SYSCALL $SYS_clock_gettime + MOVD 32(R1), R3 + MOVD 48(R1), R5 + JMP finish + +But upon inspection, it seems the offset while loading R5 is not correct: + +in QEMU's clock_gettime implementation: +(gdb) p/x *host_ts +$8 = {tv_sec = 0x9225f, tv_nsec = 0x375f74ee} + +in the Go runtime: +(gdb) p/x *($r1 + 48) +$6 = 0x388c8 +(gdb) p/x *($r1 + 40) +$7 = 0x375f74ee + + +Thank you Fabiano for investigating. + +It seems the golang side agrees with your analysis: +https://github.com/golang/go/issues/36592 + +I have marked this bug invalid for now. Thank you for your help. + +Regards, +Patrick + diff --git a/results/classifier/zero-shot/108/none/1860610 b/results/classifier/zero-shot/108/none/1860610 new file mode 100644 index 000000000..8bf6213ea --- /dev/null +++ b/results/classifier/zero-shot/108/none/1860610 @@ -0,0 +1,35 @@ +other: 0.344 +graphic: 0.334 +semantic: 0.270 +performance: 0.179 +device: 0.171 +socket: 0.134 +network: 0.115 +debug: 0.108 +vnc: 0.096 +boot: 0.050 +PID: 0.048 +permissions: 0.032 +KVM: 0.031 +files: 0.013 + +cap_disas_plugin leaks memory + +Looking at origin/master head, the function cap_disas_plugin leaks memory. + +per capstone's examples using their ABI, cs_free(insn, count); needs to called just before cs_close. + +I discovered this running qemu under valgrind. + +It looks like this will fail on all the other capstone cases as well. Is this an API change across versions? + +I run git blame in the capstone repository, and cs_free has been around for at least 4 years in the capstone ABI. I can not tell if the need to call cs_free is a (new) requirement. Documentation capstone is a little informal... + +What command line where you using? I've been unable to replicate the valgrind warning with a riscv64-linux-user run of hello with the libhowvec.so plugin. Valgrind does complain about a bunch of other stuff though. + +Looking at the way disas is structured it seems cap_insn is allocated once (per thread) and re-used for each disassembly so we shouldn't be free'ing it after each usage. In fact the comments to cap_disas_start imply we want to do better than re-initialising the library for every set of instructions we disassemble. + +It is true that we don't clean-up any of the disassembly machinery on exit but the same can be said for a lot of QEMU's static state. So currently I don't see a leak rather than a one-time allocation. Unless I can reproduce the leak I'm going to mark this as incomplete for now. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1860742 b/results/classifier/zero-shot/108/none/1860742 new file mode 100644 index 000000000..654a41900 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1860742 @@ -0,0 +1,77 @@ +boot: 0.589 +device: 0.575 +permissions: 0.536 +PID: 0.476 +socket: 0.468 +graphic: 0.374 +other: 0.354 +semantic: 0.336 +performance: 0.335 +files: 0.327 +vnc: 0.292 +debug: 0.234 +network: 0.213 +KVM: 0.137 + +xv6 Bootloop + +Qemu Version: 4.2.0 + +Launch command: +qemu-system-x86_64 -nographic -drive file=fs.img,index=1,media=disk,format=raw -drive file=xv6.img,index=0,media=disk,format=raw -smp 2 -m 512 + +How to reproduce? +1.) Use/install latest release of qemu (4.2.0 at time of writing) + +2.) Download, build, and run xv6 (a simple os designed for learning operating systems fundamentals) + +cd /tmp +git clone https://github.com/mit-pdos/xv6-public.git +cd xv6-public +make qemu-nox + +3.) Qemu should now bootloop (seem to try to boot but then just repeat). This is what it looks like below before it repeats: + +SeaBIOS (version ?-20191223_100556-anatol) + +iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+1FF92A50+1FEF2A50 CA00 + +Booting from Hard Disk.. + + + +Host: Arch Linux - Kernel version: 5.4.13 +Guest: xv6 (https://github.com/mit-pdos/xv6-public) + +Suspicion: + +When I was using qemu 2.11.1 inside docker, the xv6 os booted with no problem. I am thinking that something changed between Qemu 2.11.1 and Qemu 4.2.0 which is now causing boot problems. + +Also in my ubuntu 19.10 system. + +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. + + +Still seems to be an issue for me. + +Qemu Version 5.2.0 +Arch Linux 5.11.16-arch1-1 + + +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/192 + + diff --git a/results/classifier/zero-shot/108/none/1861562 b/results/classifier/zero-shot/108/none/1861562 new file mode 100644 index 000000000..126fd1df7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1861562 @@ -0,0 +1,189 @@ +other: 0.569 +permissions: 0.533 +device: 0.489 +semantic: 0.487 +debug: 0.477 +vnc: 0.466 +files: 0.438 +PID: 0.433 +boot: 0.422 +performance: 0.419 +graphic: 0.418 +socket: 0.410 +KVM: 0.402 +network: 0.339 + +piix crashes on mips when using multiple cpus + +Crash occurred while testing commit 330edfcc84a7: + +$ qemu-system-mips64el -cpu I6400 -append "clocksource=GIC console=ttyS0" -smp 8 -kernel vmlinux +Linux version 4.7.0-rc1 (phil@x1) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Sat Feb 1 13:15:19 UTC 2020 +earlycon: uart8250 at I/O port 0x3f8 (options '38400n8') +bootconsole [uart8250] enabled +CPU0 revision is: 0001a900 (MIPS I6400) +FPU revision is: 20f30300 +MSA revision is: 00000300 +MIPS: machine is mti,malta +Software DMA cache coherency enabled +Determined physical RAM map: + memory: 0000000008000000 @ 0000000000000000 (usable) +Zone ranges: + DMA [mem 0x0000000000000000-0x0000000000ffffff] + DMA32 [mem 0x0000000001000000-0x00000000ffffffff] + Normal empty +Movable zone start for each node +Early memory node ranges + node 0: [mem 0x0000000000000000-0x0000000007ffffff] +Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] +VP topology {8} total 8 +Primary instruction cache 64kB, VIPT, 4-way, linesize 64 bytes. +Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 64 bytes +percpu: Embedded 5 pages/cpu @980000000107c000 s29664 r8192 d44064 u81920 +Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8163 +Kernel command line: clocksource=GIC console=ttyS0 +log_buf_len individual max cpu contribution: 4096 bytes +log_buf_len total cpu_extra contributions: 28672 bytes +log_buf_len min size: 32768 bytes +log_buf_len: 65536 bytes +early log buf free: 30432(92%) +PID hash table entries: 512 (order: -2, 4096 bytes) +Dentry cache hash table entries: 16384 (order: 3, 131072 bytes) +Inode-cache hash table entries: 8192 (order: 2, 65536 bytes) +Writing ErrCtl register=00000000 +Readback ErrCtl register=00000000 +MAAR configuration: + [0]: 0x0000000000010000-0x0000000007ffffff speculate + [1]: disabled + [2]: disabled + [3]: disabled + [4]: disabled + [5]: disabled + [6]: disabled + [7]: disabled +Memory: 121104K/131072K available (5253K kernel code, 380K rwdata, 1276K rodata, 304K init, 278K bss, 9968K reserved, 0K cma-reserved) +Hierarchical RCU implementation. + Build-time adjustment of leaf fanout to 64. +NR_IRQS:256 +CPU frequency 200.00 MHz +GIC frequency 100.00 MHz +clocksource: GIC: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112702515 ns +clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112355619 ns +sched_clock: 32 bits at 100MHz, resolution 9ns, wraps every 21474556923ns +... +Primary instruction cache 64kB, VIPT, 4-way, linesize 64 bytes. +Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 64 bytes +CPU7 revision is: 0001a900 (MIPS I6400) +FPU revision is: 20f30300 +MSA revision is: 00000300 +Synchronize counters for CPU 7: done. +Brought up 8 CPUs +devtmpfs: initialized +clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +NET: Registered protocol family 16 +pm-cps: CPC does not support clock gating +vgaarb: loaded +SCSI subsystem initialized +PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [mem 0x10000000-0x17ffffff] +pci_bus 0000:00: root bus resource [io 0x1000-0x1fffff] +pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] +pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] +pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x20: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x24: invalid BAR (can't size) +pci 0000:00:0a.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x14: [io 0x03f6] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x1c: [io 0x0376] +Aborted (core dumped) + +(gdb) bt +#0 0x00007fe1e8d37e35 in raise () at /lib64/libc.so.6 +#1 0x00007fe1e8d22895 in abort () at /lib64/libc.so.6 +#2 0x000055d442b388ba in acpi_gpe_ioport_get_ptr (addr=addr@entry=49312, ar=ar@entry=0x55d4444212d0) at hw/acpi/core.c:670 +#3 0x000055d442b388ba in acpi_gpe_ioport_writeb (ar=ar@entry=0x55d4444212d0, addr=addr@entry=49312, val=val@entry=181) at hw/acpi/core.c:680 +#4 0x000055d442d3f363 in gpe_writeb (opaque=0x55d444420800, addr=49312, val=181, width=<optimized out>) at hw/acpi/piix4.c:553 +#5 0x000055d442b9534b in memory_region_write_accessor (mr=mr@entry=0x55d4444211e0, addr=49312, value=value@entry=0x7fe1ddff9ef8, size=size@entry=1, shift=<optimized out>, mask=mask@entry=255, attrs=...) + at memory.c:483 +#6 0x000055d442b9305e in access_with_adjusted_size (addr=addr@entry=49312, value=value@entry=0x7fe1ddff9ef8, size=size@entry=8, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry= + 0x55d442b95220 <memory_region_write_accessor>, mr=0x55d4444211e0, attrs=...) at memory.c:544 +#7 0x000055d442b976b4 in memory_region_dispatch_write (mr=mr@entry=0x55d4444211e0, addr=addr@entry=49312, data=<optimized out>, data@entry=327163317, op=op@entry=MO_64, attrs=...) at memory.c:1475 +#8 0x000055d442ba44fd in io_writex + (env=env@entry=0x55d443ec8f60, mmu_idx=mmu_idx@entry=0, val=val@entry=327163317, addr=addr@entry=10376293541929074848, retaddr=140608199778784, op=MO_64, iotlbentry=<optimized out>, iotlbentry=<optimized out>) + at accel/tcg/cputlb.c:980 +#9 0x000055d442baa43c in store_helper (op=MO_64, retaddr=140608199778784, oi=<optimized out>, val=<optimized out>, addr=10376293541929074848, env=0x55d443ec8f60) at accel/tcg/cputlb.c:1788 +#10 0x000055d442baa43c in helper_le_stq_mmu (env=0x55d443ec8f60, addr=10376293541929074848, val=327163317, oi=<optimized out>, retaddr=140608199778784) at accel/tcg/cputlb.c:1920 +#11 0x00007fe1e5cce1e0 in code_gen_buffer () +#12 0x000055d442bbc6d3 in cpu_tb_exec (itb=<optimized out>, cpu=0x0) at accel/tcg/cpu-exec.c:172 +#13 0x000055d442bbc6d3 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x0) at accel/tcg/cpu-exec.c:618 +#14 0x000055d442bbc6d3 in cpu_exec (cpu=cpu@entry=0x55d443ec0550) at accel/tcg/cpu-exec.c:731 +#15 0x000055d442b88580 in tcg_cpu_exec (cpu=0x55d443ec0550) at cpus.c:1405 +#16 0x000055d442b8a6f4 in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x55d443ec0550) at cpus.c:1713 +#17 0x000055d442faeb7b in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:519 +#18 0x00007fe1e8ece4c0 in start_thread () at /lib64/libpthread.so.0 +#19 0x00007fe1e8dfc163 in clone () at /lib64/libc.so.6 + +ACPI GPE was added in: + +commit 5e3cb5347e9b650bdf8015da3c310b2669219294 +Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162> +Date: Wed Feb 11 15:21:35 2009 +0000 + + qemu: initialize hot add system / acpi gpe (Marcelo Tosatti) + + ACPI GPE support, used by PCI (and CPU) hotplug. + + From: Glauber Costa <email address hidden> + Signed-off-by: Marcelo Tosatti <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + +GPE_LEN=4 definition was added in: + +commit 23910d3f669d46073b403876e30a7314599633af +Author: Isaku Yamahata <email address hidden> +Date: Fri Mar 25 19:54:41 2011 +0900 + + acpi, acpi_piix: factor out GPE logic + + factor out ACPI GPE logic. Later it will be used by ICH9 ACPI. + + Signed-off-by: Isaku Yamahata <email address hidden> + Signed-off-by: Aurelien Jarno <email address hidden> + +I am not sure what '4' means here. + +Note, Linux kernels "256 GPEs can be masked": +https://github.com/torvalds/linux/commit/a7583e72a5f22 + +I can not find reference to GPE in the PIIX4 datasheet (290562-001). + + +The Malta + I6400 boots properly when disabling this feature using: +-- >8 --- +--- a/hw/acpi/piix4.c ++++ b/hw/acpi/piix4.c +@@ -502,9 +502,11 @@ static void piix4_pm_realize(PCIDevice *dev, Error **errp) + s->machine_ready.notify = piix4_pm_machine_ready; + qemu_add_machine_init_done_notifier(&s->machine_ready); + ++ if (0) { + piix4_acpi_system_hot_add_init(pci_address_space_io(dev), + pci_get_bus(dev), s); + qbus_set_hotplug_handler(BUS(pci_get_bus(dev)), OBJECT(s), &error_abort); ++ } + + piix4_pm_add_propeties(s); + } +--- + + +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/193 + + diff --git a/results/classifier/zero-shot/108/none/1862986 b/results/classifier/zero-shot/108/none/1862986 new file mode 100644 index 000000000..96297b579 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1862986 @@ -0,0 +1,157 @@ +graphic: 0.420 +device: 0.412 +other: 0.412 +permissions: 0.404 +debug: 0.359 +semantic: 0.359 +files: 0.318 +PID: 0.309 +network: 0.281 +performance: 0.278 +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/zero-shot/108/none/1863445 b/results/classifier/zero-shot/108/none/1863445 new file mode 100644 index 000000000..440dcfa48 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1863445 @@ -0,0 +1,58 @@ +debug: 0.540 +device: 0.454 +PID: 0.448 +socket: 0.412 +vnc: 0.378 +performance: 0.364 +network: 0.288 +semantic: 0.272 +other: 0.247 +boot: 0.200 +permissions: 0.181 +files: 0.172 +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/zero-shot/108/none/1863601 b/results/classifier/zero-shot/108/none/1863601 new file mode 100644 index 000000000..c186ca856 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1863601 @@ -0,0 +1,41 @@ +graphic: 0.531 +semantic: 0.475 +other: 0.406 +device: 0.328 +performance: 0.307 +network: 0.147 +vnc: 0.127 +socket: 0.126 +PID: 0.106 +debug: 0.105 +boot: 0.065 +permissions: 0.048 +files: 0.040 +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/zero-shot/108/none/1865 b/results/classifier/zero-shot/108/none/1865 new file mode 100644 index 000000000..ba561f423 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1865 @@ -0,0 +1,39 @@ +graphic: 0.558 +debug: 0.513 +device: 0.497 +PID: 0.409 +network: 0.381 +socket: 0.308 +vnc: 0.292 +semantic: 0.280 +boot: 0.242 +other: 0.214 +permissions: 0.214 +performance: 0.178 +files: 0.132 +KVM: 0.072 + +ERROR:../target/s390x/tcg/cc_helper.c:128:cc_calc_addu: assertion failed: (carry_out <= 1) +Description of problem: +Installation progresses OK, but QEMU asserts during post-installation setup tasks: + +Performing post-installation setup tasks +** +ERROR:../target/s390x/tcg/cc_helper.c:128:cc_calc_addu: assertion failed: (carry_out <= 1) +Bail out! ERROR:../target/s390x/tcg/cc_helper.c:128:cc_calc_addu: assertion failed: (carry_out <= 1) +./install.sh: line 25: 158224 Aborted (core dumped) $QEMU/qemu-system-s390x -M s390-ccw-virtio -smp 1 -m 4G +-nographic -display none -serial mon:stdio -device virtio-scsi -drive file=$ISO,format=raw,if=none,id=c1 -device scsi-cd,dri +ve=c1 -hda $DISK -kernel $KERNEL -initrd $INITRD -net nic,model=virtio,netdev=net1 -netdev user,id=net1 -D debug.log +Steps to reproduce: +1. Download ClefOS 7.7 ISO from [sinenomine](https://download.sinenomine.net/clefos) +2. Download Fedora 27 ISO and extract kernel.img and initrd.img, for boot purposes +3. Boot ClefOS ISO using Fedora kernel/initrd +4. Go through a minimal install, observe crash during post-installation setup tasks +Additional information: +See script log and install.sh attached. [install-and-output.zip](/uploads/87eb8484344402ea9c68784f89ea3339/install-and-output.zip) + +I have tried QEMU 7.2.5 and 8.1 on my Fedora 38 AMD host. + +My goal is to create RHEL7, SLES12, Ubuntu20 (or compatible) VMs for s390x software builds. +So far only Ubuntu20 has been successful. +RHEL7 fails due to kernel issues described in QEMU issue 906, so I'm trying ClefOS (CentOS for z) based on a procedure [here](https://www.linuxquestions.org/questions/linux-server-73/install-clefos-7-5-an-open-source-version-of-rhel-7-5-s390x-using-qemu-4175658710/) diff --git a/results/classifier/zero-shot/108/none/1865188 b/results/classifier/zero-shot/108/none/1865188 new file mode 100644 index 000000000..8f7eddb4c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1865188 @@ -0,0 +1,56 @@ +device: 0.552 +performance: 0.532 +network: 0.499 +files: 0.486 +permissions: 0.460 +boot: 0.458 +PID: 0.456 +semantic: 0.446 +socket: 0.437 +graphic: 0.415 +other: 0.400 +vnc: 0.340 +debug: 0.301 +KVM: 0.259 + +Switching from the monitor to the emulated machine with a French keyboard (AZERTY) + +Hi, +I run qemu in an xterm terminal, with TERM=vt100. My keyboard is french AZERTY. + +sudo ./qemu-system-hppa -monitor /dev/pts/2 -k fr -boot d -drive if=scsi,bus=0,index=5,file=../../hpux_11iv1.img,format=raw -serial mon:stdio -D qemu1.log -nographic -m 512 -d nochain -cdrom ../../distri/11iv1/'HP-UX_11iv1_B.11.11_TCOE_September_2005_1of4_Core_OS _Install&Recovery_B6821-10046.iso' -net nic,model=tulip -net tap + +When I want to use the monitor (to change cdrom during the hp-ux installation process), the characters I type are misinterpreted. For example, I enter "2" at hp-ux prompt, I see : "412691;82;22". Impossible to switch from monitor to hp-ux with Ctrl+Alt+1 and Ctrl+Alt+2. + +I tried with Debian and Fedora host, TERM=xterm and TERM=vt100, qemu options -alt-grab and -ctrl-grab, -monitor in the same terminal or an other terminal than hp-ux. Nothing works. +Best regards. + +In an xterm to switch to/from QEMU monitor use "Ctrl-A c" + +Thank you for your reply. It works well with "Ctrl-A c" to swith to and from QEMU monitor in xterm terminal. + +The problem is elsewhere, with the option -monitor. With "-monitor <tty device>", whether <tty device> is or not the tty from which qemu is started, the characters I type are misinterpreted. Maybe I must report this bug ? + +Now, I remove the -monitor option, and I add "-serial mon:telnet::4444,server" before "-serial mon:stdio". I enter the following command in a first xterm, and "telnet localhost 4444" in a second xterm. So, qemu monitor works fine in the first xterm, and HP-UX installation menu is correctly displayed in the second xterm. + +The command : +sudo ./qemu-system-hppa -boot d -drive if=scsi,bus=0,index=5,file=../../hpux_11.00.img,format=raw -serial mon:telnet::4444,server -serial mon:stdio -nographic -m 512 -d nochain -cdrom ../../distri/11.00/'HP-UX 11.0 (2002-06).iso' -D qemu.log -net nic,model=tulip -net tap + +Now, I will try to use the graphic mode. +Have a nice day, +Thierry Briot + +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/zero-shot/108/none/1865626 b/results/classifier/zero-shot/108/none/1865626 new file mode 100644 index 000000000..b789821af --- /dev/null +++ b/results/classifier/zero-shot/108/none/1865626 @@ -0,0 +1,53 @@ +device: 0.585 +performance: 0.573 +boot: 0.552 +socket: 0.550 +PID: 0.481 +semantic: 0.399 +permissions: 0.346 +debug: 0.300 +graphic: 0.264 +network: 0.245 +other: 0.235 +files: 0.216 +vnc: 0.196 +KVM: 0.007 + +s390x guest hang when ipl boot from a mdev dasd + +qemu latest +kernel 5.3.18 + +I am using a passthrough dasd as boot device, the installment looks fine and gets into reboot process. However VM could not boot and just hang as below after that. I have been checking on "s390: vfio-ccw dasd ipl support" series right now but no clue yet. Could anyone take a look for it? Thanks. + + + +s390vsw188:~ # bash test.sh +LOADPARM=[ ] +executing ccw chain at : 0x0000000000000018 +executing ccw chain at : 0x000000000000e000 + +2020-03-01T06:24:56.879314Z qemu-system-s390x: warning: vfio-ccw (devno fe.0.0000): PFCH flag forced + + + +s390zp12:~ # cat test.sh +/root/qemu/s390x-softmmu/qemu-system-s390x \ +-machine s390-ccw-virtio,accel=kvm \ +-nographic \ +-bios /root/qemu/pc-bios/s390-ccw/s390-ccw.img \ +-device vfio-ccw,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/08e8c006-146d-48d3-b21a-c005f9d3a04b,,devno=fe.0.0000,bootindex=1 \ +-global vfio-ccw.force-orb-pfch=yes \ + +s390zp12:~ # cat test.sh +/root/qemu/s390x-softmmu/qemu-system-s390x \ +-machine s390-ccw-virtio,accel=kvm \ +-nographic \ +-bios /root/qemu/pc-bios/s390-ccw/s390-ccw.img \ +-device vfio-ccw,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/08e8c006-146d-48d3-b21a-c005f9d3a04b,devno=fe.0.1234,bootindex=1 \ +-global vfio-ccw.force-orb-pfch=yes + +Can you still reproduce this issue with the latest version of QEMU? Which kind of guest did you install? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1867072 b/results/classifier/zero-shot/108/none/1867072 new file mode 100644 index 000000000..59deffa3c --- /dev/null +++ b/results/classifier/zero-shot/108/none/1867072 @@ -0,0 +1,91 @@ +graphic: 0.395 +semantic: 0.304 +device: 0.297 +performance: 0.292 +other: 0.284 +network: 0.239 +socket: 0.185 +permissions: 0.180 +vnc: 0.175 +PID: 0.150 +debug: 0.141 +files: 0.131 +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/zero-shot/108/none/1868221 b/results/classifier/zero-shot/108/none/1868221 new file mode 100644 index 000000000..8fd5593eb --- /dev/null +++ b/results/classifier/zero-shot/108/none/1868221 @@ -0,0 +1,78 @@ +socket: 0.425 +device: 0.407 +PID: 0.382 +semantic: 0.379 +files: 0.358 +permissions: 0.328 +network: 0.294 +boot: 0.257 +performance: 0.255 +graphic: 0.251 +other: 0.205 +debug: 0.196 +vnc: 0.176 +KVM: 0.092 + +/usr/share/applications/qemu.desktop should have an "Exec=" key. + +According to the www.freedesktop.org .desktop-file specification, all "Application" desktop files should have an "Exec=" key. The one in qemu doesn't. + +This can be easily verified by running kbuildsycoca4 if KDE4 is present, but the issue is not DE-dependent. + +Which binary exactly should be assigned as the default one, I don't know. + +The specification can be seen here: + +https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables + +Adding an exec field would not be right, because QEMU can't simply be launched from the desktop without any arguments. There needs to be a long string of arguments given that are different for every QEMU that is launched. The only viable way to actually launch QEMU is interactively from the terminal, or indirectly via a 3rd party app like virt-manager. We only created the qemu.desktop file in the first place because Wayland needs this to be present in order to identify what Icon to display for a window. + +Note that QEMU sets the NoDisplay=true property to tell desktops not to display this entry. I don't think KDE should be warning about missing Exec entry in this case. + + +I'll report a bug in KDE and let's see if the guys agree. Maybe it is a deficiency of the .desktop specification. + + +Thank you Lockywolf for this bug report. Have you filed one against KDE as you previously mentioned? If so, could you provide us with a link? Thanks in advance! + +I am sorry I haven't dealt with this bug for quite a while. KDE 5 is not properly working on my distro, and I wanted to test it when it stabilises. + +If qemu dislikes long-standing bugs, this bug can be closed, and I'll open a new one when I have time to test it on the new KDE. + + +What's the actual problem we're trying to solve here? What needs to be tested? + +I can confirm that this behaviour is still present on kde 5.20.4. + +You can run e.g. khelpcenter and observe: + +kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec line +kf.service.sycoca: Invalid Service : "/usr/share/applications/qemu.desktop" + + +A bug on KDE bug tracker: + +https://bugs.kde.org/show_bug.cgi?id=430157 + + +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/440 + + diff --git a/results/classifier/zero-shot/108/none/1869006 b/results/classifier/zero-shot/108/none/1869006 new file mode 100644 index 000000000..af2e78073 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1869006 @@ -0,0 +1,356 @@ +other: 0.572 +KVM: 0.533 +device: 0.524 +boot: 0.485 +debug: 0.483 +permissions: 0.472 +performance: 0.470 +graphic: 0.465 +PID: 0.452 +semantic: 0.445 +network: 0.443 +socket: 0.425 +files: 0.416 +vnc: 0.379 + +PCIe cards passthrough to TCG guest works on 2GB of guest memory but fails on 4GB (vfio_dma_map invalid arg) + +During one meeting coworker asked "did someone tried to passthrough PCIe card to other arch guest?" and I decided to check it. + +Plugged SATA and USB3 controllers into spare slots on mainboard and started playing. On 1GB VM instance it worked (both cold- and hot-plugged). On 4GB one it did not: + +Błąd podczas uruchamiania domeny: internal error: process exited while connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22 +2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:29:00.0: failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument) + +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 1279, in startup + self._backend.create() + File "/usr/lib64/python3.8/site-packages/libvirt.py", line 1234, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22 +2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:29:00.0: failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument) + + +I played with memory and 3054 MB is maximum value possible to boot VM with coldplugged host PCIe cards. + +Qemu command line for booting VM was generated by libvirt: + +/usr/bin/qemu-system-aarch64 +-name guest=fedora-aarch64-pcie,debug-threads=on +-S +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-fedora-aarch64-pcie/master-key.aes +-blockdev {"driver":"file","filename":"/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw","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/fedora-aarch64-pcie_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 virt-4.2,accel=tcg,usb=off,dump-guest-core=off,gic-version=2,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format +-cpu cortex-a57 +-m 2048 +-overcommit mem-lock=off +-smp 3,sockets=3,cores=1,threads=1 +-uuid 139dc97a-1511-480d-b215-c58a5c80e646 +-no-user-config +-nodefaults +-chardev socket,id=charmonitor,fd=32,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control +-rtc base=utc +-no-shutdown +-boot strict=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 pcie-root-port,port=0xf,chassis=8,id=pci.8,bus=pcie.0,addr=0x1.0x7 +-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 +-netdev tap,fd=29,id=hostnet0 +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:87:3e:d3,bus=pci.1,addr=0x0 +-chardev pty,id=charserial0 +-serial chardev:charserial0 +-chardev socket,id=charchannel0,fd=33,server,nowait +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 +-spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on +-device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.7,addr=0x0 +-device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0 +-device vfio-pci,host=0000:28:00.0,id=hostdev1,bus=pci.4,addr=0x0 +-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 +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny +-msg timestamp=on + + + +lspci -vvv output of used cards (host side): + +28:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI]) + DeviceName: RTL8111EPV + 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 42 + Region 0: Memory at f7700000 (64-bit, non-prefetchable) [size=8K] + Capabilities: [50] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [90] MSI-X: Enable+ Count=8 Masked- + Vector table: BAR=0 offset=00001000 + PBA: BAR=0 offset=00001080 + Capabilities: [a0] Express (v2) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited + ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + DevCap2: Completion Timeout: Not Supported, TimeoutDis+, NROPrPrP-, LTR+ + 10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt-, EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS-, TPHComp-, ExtTPHComp- + AtomicOpsCap: 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled + AtomicOpsCtl: ReqEn- + LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1- + EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Capabilities: [150 v1] Latency Tolerance Reporting + Max snoop latency: 1048576ns + Max no snoop latency: 1048576ns + Kernel driver in use: xhci_hcd + +29:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01) + Subsystem: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller + 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 66 + Region 0: Memory at f7684000 (64-bit, non-prefetchable) [size=128] + Region 2: Memory at f7680000 (64-bit, non-prefetchable) [size=16K] + Region 4: I/O ports at c000 [size=128] + Expansion ROM at f7600000 [disabled] [size=512K] + Capabilities: [54] Power Management version 2 + Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- + Capabilities: [5c] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [70] Express (v1) Legacy Endpoint, MSI 00 + DevCap: MaxPayload 1024 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 4096 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s unlimited + ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- + AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Kernel driver in use: sata_sil24 + Kernel modules: sata_sil24 + + + +attaching as file as launched wraps in ugly way + +Hotplug to VM with 3055MB of memory ends same way: + +internal error: błąd podczas wykonać polecenia QEMU „device_add”: vfio 0000:28:00.0: failed to setup container for group 27: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x55c1aca5c5c0, 0x40000000, 0xbef00000, 0x7f3549000000) = -22 (Invalid argument) + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/addhardware.py", line 1327, in _add_device + self.vm.attach_device(dev) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 920, in attach_device + self._backend.attachDevice(devxml) + File "/usr/lib64/python3.8/site-packages/libvirt.py", line 606, in attachDevice + if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self) +libvirt.libvirtError: internal error: błąd podczas wykonać polecenia QEMU „device_add”: vfio 0000:28:00.0: failed to setup container for group 27: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x55c1aca5c5c0, 0x40000000, 0xbef00000, 0x7f3549000000) = -22 (Invalid argument) + + +14:57 < aw> hrw: under /sys/kernel/iommu_groups/ there's a reserved_regions file for every group. cat the ones associated with the groups for these devices + +14:59 < hrw> 14:58 (0s) hrw@puchatek:28$ cat reserved_regions +14:59 < hrw> 0x00000000fee00000 0x00000000feefffff msi +14:59 < hrw> 0x000000fd00000000 0x000000ffffffffff reserved + +14:59 < hrw> 14:59 (2s) hrw@puchatek:27$ cat reserved_regions +14:59 < hrw> 0x00000000fee00000 0x00000000feefffff msi +14:59 < hrw> 0x000000fd00000000 0x000000ffffffffff reserved + +15:00 < aw> of course, you're on an x86 host, arm has no concept of not mapping memory at 0xfee00000 + + +Summary: ARM64 TCG VM on x86 host has GPA overlapping host reserved IOVA regions, vfio cannot map these. The VM needs holes in the GPA to account for this. The 2nd and 3rd args of the vfio_dma_map error report are the starting IOVA address and length respectively. + +My (limited) understanding of PCI was that the board and the PCI controller emulation define what the windows are where PCI BARs can live, and that PCI cards go there. (This certainly works for emulated PCI cards.) It's not clear to me why the host system imposes restrictions on the memory layout of the VM... + + +This is not related to the BARs, the mapping of the BARs into the guest is purely virtual and controlled by the guest. The issue is that the device needs to be able to DMA into guest RAM, and to do that transparently (ie. the guest doesn't know it's being virtualized), we need to map GPAs into the host IOMMU such that the guest interacts with the device in terms of GPAs, the host IOMMU translates that to HPAs. Thus the IOMMU needs to support GPA range of the guest as IOVA. However, there are ranges of IOVA space that the host IOMMU cannot map, for example the MSI range here is handled by the interrupt remmapper, not the DMA translation portion of the IOMMU (on physical ARM systems these are one-in-the-same, on x86 they are different components, using different mapping interfaces of the IOMMU). Therefore if the guest programmed the device to perform a DMA to 0xfee00000, the host IOMMU would see that as an MSI, not a DMA. When we do an x86 VM on and x86 host, both the host and the guest have complimentary reserved regions, which avoids this issue. + +Also, to expand on what I mentioned on IRC, every x86 host is going to have some reserved range below 4G for this purpose, but if the aarch64 VM has no requirements for memory below 4G, the starting GPA for the VM could be at or above 4G and avoid this issue. + +That's an awkward flaw in the IOMMU design :-( + + +I wrote blog post about it: https://marcin.juszkiewicz.com.pl/2020/03/25/sharing-pcie-cards-across-architectures/ + +I wanted to try the same on machine without MSI. But my desktop refuses to boot into sane environment with pci=nomsi kernel option. + +Do we need something like a table of excluded IOVA regions in ACPI or somewhere; in a similar way we have a region of exluded physical ram areas? +Or is the range of excluded IOVA's constant on any one architecture so it doesn't normally need to worry about it? + +Yes, to support this the vfio driver would need to be able to exclude ranges of guest GPA space. Recent kernels already expose an IOVA list via the vfio API. Clearly, excluding GPA ranges has implications for hotplug. On x86 the ranges are pretty consistent, but IIRC differ between Intel and AMD. The vfio IOVA list was originally developed for an ARM use case though, and I imagine there's little or no consistency there. + +Re: pci=nomsi, the reserved range exists regardless of whether MSI is actually used. + +I am experiencing the same behaviour for x86_64 guest on x86_64 host to which I'm attempting to efi boot (not hotplug) with a pcie gpu passthrough + +This discussion (https://www.spinics.net/lists/iommu/msg40613.html) suggests a change in drivers/iommu/intel-iommu.c but it appears that in the kernel I tried, the change it is already implemented (linux-image-5.4.0-39-generic) + +hardware is a hp microserver gen8 with conrep physical slot excluded in bios (https://www.jimmdenton.com/proliant-intel-dpdk/) and the kernel is rebuild with rmrr patch (https://forum.proxmox.com/threads/compile-proxmox-ve-with-patched-intel-iommu-driver-to-remove-rmrr-check.36374/) + +also an user complains that on the same hardware it used to work with kernel 5.3 + rmrr patch (https://forum.level1techs.com/t/looking-for-vfio-wizards-to-troubleshoot-error-vfio-dma-map-22/153539) but it stopped working on the 5.4 kernel. + +is this the same issue I'm observing? my qemu complains with the similar message: + + -device vfio-pci,host=07:00.0,id=hostdev0,bus=pci.4,addr=0x0: vfio_dma_map(0x556eb57939f0, 0xc0000, 0x3ff40000, 0x7f6fc7ec0000) = -22 (Invalid argument) + +/sys/kernel/iommu_groups/1/reserved_regions shows: + +0x00000000000e8000 0x00000000000e8fff direct +0x00000000000f4000 0x00000000000f4fff direct +0x00000000d5f7e000 0x00000000d5f94fff direct +0x00000000fee00000 0x00000000feefffff msi + + +except that in my case the vm does not boot at all no matter how less memory I allocate to it. + +You'd need to create a 160KB VM in order to stay below the required direct map memory regions imposed by the system firmware (e8000 - c0000). Non-upstream bypasses of those restrictions are clearly not supported. You can find more details regarding the RMRR restriction here: +https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf + +QEMU currently has no support for creating a VM memory map based on the restrictions of the host platform IOMMU requirements. + +Alex, thanks for the quick answer, but sadly I still do not fully understand the implications, even if I read the pdf paper on RH website you mention, as well as the vendor advisory at https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04781229 + +When you say "qemu has no support", do you actually mean "qemu people are unable to help you if you break things by bypassing the in-place restrictions", or "qemu is designed to not work when restrictions are bypassed"? + +Do I understand correctly that the BIOS can modify portions of the system usable RAM, so the vendor specific software tools can read those addresses, and if yes, does this mean is there a risk for data corruption if the RMRR restrictions are bypassed? + +I have eventually managed to passthrough an nvidia card in the microserver gen8 to a windows vm using patched kernel 5.3, along with the vendor instructions to exclude the pcie slot aka the conrep solution but for it to work it still needed the "rmrr patch" aka removing the "return -EPERM" line below the "Device is ineligible [...]" in drivers/iommu/intel-iommu.c + + +However applying the same modification to kernel 5.4 leads to the "VFIO_MAP_DMA: -22" error. + +Is there other place in the kernel 5.4 source that must be modified to bring back the v5.3 kernel behaviour? (ie. I have a stable home windows vm with the gpu passthrough despite all) + +> When you say "qemu has no support", do you actually mean "qemu people +> are unable to help you if you break things by bypassing the in-place +> restrictions", or "qemu is designed to not work when restrictions are +> bypassed"? + +The former. There are two aspects to this. The first is that the device has address space restrictions which therefore impose address space restrictions on the VM. That makes things like hotplug difficult or impossible to support. That much is something that could be considered a feature which QEMU has not yet implemented. + +The more significant aspect when RMRRs are involved in this restriction is that an RMRR is essentially the platform firmware dictating that the host OS must maintain an identity map between the device and a range of physical address space. We don't know the purpose of that mapping, but we can assume that it allows the device to provide ongoing data for platform firmware to consume. This data might included health or sensor information that's vital to the operation of the system. It's therefore not simply a matter that QEMU needs to avoid RMRR ranges, we need to maintain the required identity maps while also manipulating the VM address space, but the former requirement implies that a user owns a device that has DMA access to a range of host memory that's been previously defined as vital to the operation of the platform and therefore likely exploitable by the user. + +The configuration you've achieved appears to have disabled the host kernel restrictions preventing RMRR encumbered devices from participating in the IOMMU API, but left in place the VM address space implications of those RMRRs. This means that once the device is opened by the user, that firmware mandated identity mapping is removed and whatever health or sensor data was being reported by the device to that range is no longer available to the host firmware, which might adversely affect the behavior of the system. Upstream put this restriction in place as the safe thing to do to honor the firmware mapping requirement and you've circumvented it, therefore you are your own support. + +> Do I understand correctly that the BIOS can modify portions of the +> system usable RAM, so the vendor specific software tools can read +> those addresses, and if yes, does this mean is there a risk for +> data corruption if the RMRR restrictions are bypassed? + +RMRRs used for devices other than IGD or USB are often associated with reserved memory regions to prevent the host OS from making use of those ranges. It is possible that privileged utilities might interact with these ranges, but AIUI the main use case is for the device to interact with the range, which firmware then consumes. If you were to ignore the RMRR mapping altogether, there is a risk that the device will continue to write whatever health or sensor data it's programmed to report to that IOVA mapping, which could be a guest mapping and cause data corruption. + +> Is there other place in the kernel 5.4 source that must be modified +> to bring back the v5.3 kernel behaviour? (ie. I have a stable home +> windows vm with the gpu passthrough despite all) + +I think the scenarios is that previously the RMRR patch worked because the vfio IOMMU backend was not imposing the IOMMU reserved region mapping restrictions, meaning that it was sufficient to simply allow the device to participate in the IOMMU API and the remaining restrictions were ignored. Now the vfio IOMMU backend recognizes the address space mapping restrictions and disallows creating those mappings that I describe above as a potential source of data corruption. Sorry, you are your own support for this. The system is not fit for this use case due to the BIOS imposed restrictions. + +@alex-l-williamson: is there any safe(ish) way to ignore RMRR coming from BIOS? + +I don't know how IOMMU actually works in the kernel but theoretically if kernel had a flag forcing it to ignore certain RMRRs? If I understand this correctly ignoring an RMRR entry may cause two things: +1) DMA failure if remapping is attempted +2) If something (e.g. KVM) touches that region because we ignored RMRR the device memory may get corrupted + +Linux already has mechanisms to ignore stubborn BIOSes (e.g. disabled x2APIC with no option to enable it in the BIOS). + + + +The only thing I'm worried about is the thing you said: +> The more significant aspect when RMRRs are involved in this restriction is that an RMRR is +> essentially the platform firmware dictating that the host OS must maintain an identity map +> between the device and a range of physical address space. We don't know the purpose of that +> mapping, but we can assume that it allows the device to provide ongoing data for platform +> firmware to consume. + +Does this mean that if a kernel is "blind" to a given RMRR region something else may break because these regions need to be treated in some special manner outside of not touching them for IOMMU? + +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/zero-shot/108/none/1869426 b/results/classifier/zero-shot/108/none/1869426 new file mode 100644 index 000000000..4be3447d2 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1869426 @@ -0,0 +1,99 @@ +device: 0.577 +permissions: 0.527 +PID: 0.470 +graphic: 0.454 +semantic: 0.427 +performance: 0.415 +network: 0.406 +files: 0.390 +other: 0.370 +socket: 0.354 +boot: 0.342 +debug: 0.333 +vnc: 0.320 +KVM: 0.261 + +5.0rc0->4.2 serial migraiton + +Migrating from 5.0rc0->4.2 with pc-q35-4.2 we get an error: + +Unknown savevm section or instance 'serial' 1 + +dumping the migration streams it looks like 5.0 is duplicating the serial migration data: + + "serial (26)": { + "divider": "0x000c", + "rbr": "0x00", + "ier": "0x00", + "iir": "0x01", + "lcr": "0x00", + "mcr": "0x00", + "lsr": "0x60", + "msr": "0xb0", + "scr": "0x00", + "fcr_vmstate": "0x00" + }, + "serial (27)": { + "state": { + "divider": "0x000c", + "rbr": "0x00", + "ier": "0x00", + "iir": "0x01", + "lcr": "0x00", + "mcr": "0x00", + "lsr": "0x60", + "msr": "0xb0", + "scr": "0x00", + "fcr_vmstate": "0x00" + } + }, + +git bisect says: + +c9808d602813bce4fada7bf9ecc463aa779b73f7 is the first bad commit +commit c9808d602813bce4fada7bf9ecc463aa779b73f7 +Author: Marc-André Lureau <email address hidden> +Date: Tue Oct 22 01:02:50 2019 +0200 + + serial: realize the serial device + + Instead of calling serial_realize_core(), use the QDev realize + callback. + + Signed-off-by: Marc-André Lureau <email address hidden> + Reviewed-by: Philippe Mathieu-Daudé <email address hidden> + + +Marc-Andre: I think you're ending up with two top level objects with vmsd's + +I thought backward migration wasn't supported. + +Isn't it this commit? + +commit 4cc017e505df7e5344e4dfe7fc17711117c5f11f +Author: Marc-André Lureau <email address hidden> +Date: Tue Oct 22 00:32:41 2019 +0200 + + serial: register vmsd with DeviceClass + + Migration from old to new code works, however the other way fails for + devices that use serial_init/serial_mm_init with "base", used as + instance_id previously. + + (with qdev_set_legacy_instance_id, the alias_id is only used in + savevm.c:find_se(), and thus can only be used to match against + "legacy" instance id values. On new code, instance_id is generated + incrementally from 0 with calculate_new_instance_id(), based on + "qdev-path/vmsd-name") + + Signed-off-by: Marc-André Lureau <email address hidden> + Reviewed-by: xiaoqiang zhao <zxq_yx_007@163.com> + + +Fix posted: +https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg08803.html + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=f602d047ac21 + + diff --git a/results/classifier/zero-shot/108/none/1873898 b/results/classifier/zero-shot/108/none/1873898 new file mode 100644 index 000000000..c4ee991ea --- /dev/null +++ b/results/classifier/zero-shot/108/none/1873898 @@ -0,0 +1,59 @@ +device: 0.554 +graphic: 0.552 +network: 0.536 +files: 0.520 +semantic: 0.510 +socket: 0.496 +performance: 0.486 +permissions: 0.466 +other: 0.458 +debug: 0.441 +vnc: 0.432 +PID: 0.367 +boot: 0.316 +KVM: 0.182 + +arm linux-user: bkpt insn doesn't cause SIGTRAP + +QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signals. Test case: + +===begin bkpt.c=== +/* test bkpt insn */ + +#include <stdlib.h> +#include <stdio.h> + +int main(void) +{ + printf("breakpoint\n"); +#ifdef __aarch64__ + __asm__ volatile("brk 0x42\n"); +#else + __asm__ volatile("bkpt 0x42\n"); +#endif + printf("done\n"); + return 0; +} +===endit=== + +Compile with +$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c +$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c + +Contrast aarch64 which delivers the SIGTRAP and arm which doesn't: + +$ qemu-aarch64 bkpt-aa64 +breakpoint +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap (core dumped) +$ qemu-arm bkpt-aa32 +breakpoint +done + +This is because in linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a syscall (which one depends on what happens to be in r7...). This code has been like this (more or less) since commit 06c949e62a098f in 2006 which added BKPT in the first place. This is probably because at the time the same code path was used to handle both Linux syscalls and semihosting calls, and (on M profile) BKPT does imply a semihosting call. But these days we've moved handling of semihosting out to an entirely different codepath, so we can fix this bug by simply removing this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like EXCP_DEBUG (as we do already on aarch64). + +Should be fixed in current git, will be in 5.2. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=13a0c21e64bddf1a36 + diff --git a/results/classifier/zero-shot/108/none/1874674 b/results/classifier/zero-shot/108/none/1874674 new file mode 100644 index 000000000..fab44d0c9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1874674 @@ -0,0 +1,77 @@ +graphic: 0.495 +performance: 0.492 +permissions: 0.480 +other: 0.469 +PID: 0.455 +device: 0.421 +network: 0.396 +socket: 0.357 +debug: 0.344 +boot: 0.339 +semantic: 0.313 +files: 0.302 +vnc: 0.300 +KVM: 0.255 + +[Feature request] acceptance test class to run user-mode binaries + +Currently the acceptance test framework only target system-mode emulation. +It would be useful to test user-mode too. + +Ref: https://<email address hidden>/msg626610.html + +What user-mode testing do you think might be improved by using avocado? + +IMO at present we have a fairly comprehensive testing infrastructure for user-mode that is simply underused. With docker, we have a set of cross-compilers for most guest architectures, and we are able to build statically linked binaries that are copied out of the container for testing by the just-built qemu binaries on the host. This infrastructure is used by check-tcg. It's fairly easy to add new test cases to be run on one or all guests. + +On 4/24/20 9:14 PM, Richard Henderson wrote: +> What user-mode testing do you think might be improved by using avocado? + +Test unmodified real-world binaries, know to work in the field. + +Test can be added by users without having to be a TCG developer, see +https://<email address hidden>/msg626608.html: + + class LoadBFLT(LinuxUserTest): + def test_stm32(self): + rootfs_url = ('https://elinux.org/images/5/51/' + 'Stm32_mini_rootfs.cpio.bz2') + rootfs_path_bz2 = self.fetch_asset(rootfs_url, ...) + busybox_path = self.workdir + "/bin/busybox" + + res = self.run("%s %s" % (busybox_path, cmd)) + ver = 'BusyBox v1.24.0.git (2015-02-03 22:17:13 CET) ...' + self.assertIn(ver, res.stdout_text) + + cmd = 'uname -a' + res = self.run("%s %s" % (busybox_path, cmd)) + unm = 'armv7l GNU/Linux' + self.assertIn(unm, res.stdout_text) + +This is a fairly trivial test, cheap (no need to cross-build), yet it +still covers quite some QEMU code. + +> IMO at present we have a fairly comprehensive testing infrastructure for +> user-mode that is simply underused. With docker, we have a set of +> cross-compilers for most guest architectures, and we are able to build +> statically linked binaries that are copied out of the container for +> testing by the just-built qemu binaries on the host. This +> infrastructure is used by check-tcg. It's fairly easy to add new test +> cases to be run on one or all guests. + +What you describe is a different and complementary test set. Craft tests +and build them with 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. + + + +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/82 + + diff --git a/results/classifier/zero-shot/108/none/1875702 b/results/classifier/zero-shot/108/none/1875702 new file mode 100644 index 000000000..73da430f0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1875702 @@ -0,0 +1,46 @@ +semantic: 0.439 +device: 0.425 +socket: 0.400 +network: 0.387 +other: 0.338 +files: 0.233 +debug: 0.171 +PID: 0.169 +vnc: 0.162 +boot: 0.131 +performance: 0.103 +graphic: 0.088 +permissions: 0.082 +KVM: 0.065 + +madvise reports success, but doesn't implement WIPEONFORK. + +The implementation of madvise (linux-user/syscall.c:11331, tag v5.0.0-rc4) always returns zero (i.e. success). However, an application requesting (at least) MADV_WIPEONFORK may need to know whether the call was actually successful. If not (because the kernel doesn't support WIPEONFORK) then it will need to take other measures to provide fork-safety (such as drawing entropy from the kernel in every case). But, if the application believes that WIPEONFORK is supported (because madvise returned zero), but it actually isn't (as in qemu), then it may forego those protections on the assumption that WIPEONFORK will provide fork-safety. + +Roughly, the comment in qemu that says "This is a hint, so ignoring and returning success is ok." is no longer accurate in the presence of MADV_WIPEONFORK. + +(This is not purely academic: BoringSSL is planning on acting in this way. We found the qemu behaviour in pre-release testing and are planning on making an madvise call with advice=-1 first to test whether unknown advice values actually produce EINVAL.) + +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. + + +Still relevant. See also bug #1926521 -- MADV_DONTNEED is another madvise() value that can't be ignored as "just a hint". + + + +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/343 + + diff --git a/results/classifier/zero-shot/108/none/1877136 b/results/classifier/zero-shot/108/none/1877136 new file mode 100644 index 000000000..a66580aab --- /dev/null +++ b/results/classifier/zero-shot/108/none/1877136 @@ -0,0 +1,79 @@ +debug: 0.248 +vnc: 0.236 +device: 0.233 +KVM: 0.232 +PID: 0.216 +semantic: 0.213 +permissions: 0.203 +boot: 0.190 +performance: 0.187 +other: 0.183 +network: 0.178 +graphic: 0.156 +socket: 0.150 +files: 0.131 + +Qemu GDB Arm core registers XML description not valid for M-profile + +When trying to debug an armv7-m binary running on Qemu, GDB makes some mistakes due to mistakenly believing the target is not M-profile. + +One observable is that backtraces over signal handlers are not handled correctly -- since the special M-profile EXC_RETURN value is not recognised. That happens because GDB doesn't think the target is M-profile. + +This happens because GDB sees a reported feature set from the Qemu remote connection that includes the feature `org.gnu.gdb.arm.core`. + +As described in the GDB online docs, for "M-profile targets (e.g. Cortex-M3), the ‘org.gnu.gdb.arm.core’ feature is replaced by ‘org.gnu.gdb.arm.m-profile’" +https://sourceware.org/gdb/current/onlinedocs/gdb/ARM-Features.html + +From a scan of the Qemu source code on commit ea1329bb3a8d5cd25b70e3dbf73e7ded4d5ad756 it seems that when emulating an arm core it uses `arm-core.xml` unconditionally for `CPUClass->gdb_core_xml_file`, and that means the only feature provided is `org.gnu.gdb.arm.core`. + +Note that even though there is a command to set the architecture in GDB, setting the target architecture to an M-profile core is still not a valid workaround. +This is because the target description overrides everything in setting the `is_m` attribute within GDB. + +Reproduction of the observable: +Using the examples here https://git.linaro.org/people/peter.maydell/m-profile-tests.git/tree/ . +Build the examples, and run +``` +qemu-system-arm -s -S -no-reboot -M lm3s6965evb -m 16 -serial stdio -display none -net nic -net user,restrict=on -d guest_errors,unimp -kernel test3-kern.bin +``` + +Then in a GDB session +``` +vshcmd: > arm-none-eabi-gdb -q +(gdb) +vshcmd: > file test3-kern.elf +Reading symbols from test3-kern.elf... +(gdb) +vshcmd: > target remote localhost:1234 +Remote debugging using localhost:1234 +_start () at init-m.S:53 +53 mov r0, #0 +(gdb) +vshcmd: > show architecture +The target architecture is set automatically (currently armv7) +(gdb) +vshcmd: > break svc +Breakpoint 1 at 0x6fc: svc. (2 locations) +(gdb) +vshcmd: > cont +Continuing. + +Breakpoint 1, svc () at test3.c:16 +16 int test = SEQ(); +(gdb) +vshcmd: > bt +#0 svc () at test3.c:16 +#1 0xfffffff8 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) +vshcmd: > print/x $lr +$1 = 0xfffffff9 +(gdb) +``` + +Patch submitted: https://<email address hidden>/ + + +Fix now in master, will be in QEMU 5.1. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c888f7e0fdcc09c8600 + diff --git a/results/classifier/zero-shot/108/none/1879227 b/results/classifier/zero-shot/108/none/1879227 new file mode 100644 index 000000000..08c0e6ef5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1879227 @@ -0,0 +1,84 @@ +vnc: 0.474 +KVM: 0.463 +other: 0.403 +graphic: 0.368 +files: 0.341 +debug: 0.338 +device: 0.326 +PID: 0.323 +semantic: 0.320 +permissions: 0.310 +performance: 0.309 +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/zero-shot/108/none/1879646 b/results/classifier/zero-shot/108/none/1879646 new file mode 100644 index 000000000..e8a85759d --- /dev/null +++ b/results/classifier/zero-shot/108/none/1879646 @@ -0,0 +1,54 @@ +KVM: 0.450 +device: 0.406 +debug: 0.338 +socket: 0.337 +semantic: 0.331 +boot: 0.317 +graphic: 0.311 +network: 0.303 +performance: 0.225 +other: 0.208 +files: 0.208 +PID: 0.205 +vnc: 0.189 +permissions: 0.127 + +[Feature request] x86: dump MSR features in human form + +QEMU might fail because host/guest cpu features are not properly configured: + +qemu-system-x86_64: error: failed to set MSR 0x48f to 0x7fefff00036dfb +qemu-system-x86_64: /root/qemu-master/target/i386/kvm.c:2695: +kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +To ease debugging, it the MSR features bit could be dumped. + +Example in this thread: + +https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05593.html + + The high 32 bits are 0111 1111 1110 1111 1111 1111. + + The low 32 bits are 0000 0011 0110 1101 1111 1011. + + The features that are set are the xor, so 0111 1100 1000 0010 0000 0100: + + - bit 2, vmx-exit-nosave-debugctl + - bit 9, host address space size, is handled automatically by QEMU + - bit 15, vmx-exit-ack-intr + - bit 17, vmx-exit-save-pat + - bit 18, vmx-exit-load-pat + - bit 19, vmx-exit-save-efer + - bit 20, vmx-exit-load-efer + - bit 21, vmx-exit-save-preemption-timer + +This output ^^^ is easier to digest. + + +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/237 + + diff --git a/results/classifier/zero-shot/108/none/1880763 b/results/classifier/zero-shot/108/none/1880763 new file mode 100644 index 000000000..bc47b3b88 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1880763 @@ -0,0 +1,68 @@ +other: 0.557 +device: 0.544 +PID: 0.535 +semantic: 0.462 +performance: 0.456 +permissions: 0.452 +network: 0.437 +socket: 0.402 +files: 0.380 +vnc: 0.356 +graphic: 0.317 +boot: 0.304 +KVM: 0.273 +debug: 0.215 + +Missing page crossing check in use_goto_tb() for rx target + +Currently the rx target doesn't have the page crossing check in its +use_goto_tb() function. +This is a required feature for stable system mode emulations that all +other targets implement. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +For the record, this was fixed for 6.1 in + +commit f3f713cc151086ca39d4f97270594fd8c43e17e5 +Author: Richard Henderson <email address hidden> +Date: Sun Jun 20 16:37:12 2021 -0700 + + target/rx: Use translator_use_goto_tb + + Just use translator_use_goto_tb directly at the one call site, + rather than maintaining a local wrapper. + + Reviewed-by: Peter Maydell <email address hidden> + Signed-off-by: Richard Henderson <email address hidden> + + + diff --git a/results/classifier/zero-shot/108/none/1884982 b/results/classifier/zero-shot/108/none/1884982 new file mode 100644 index 000000000..007166b44 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1884982 @@ -0,0 +1,45 @@ +files: 0.431 +device: 0.336 +boot: 0.303 +socket: 0.284 +network: 0.275 +other: 0.265 +semantic: 0.256 +permissions: 0.216 +vnc: 0.205 +debug: 0.180 +PID: 0.142 +graphic: 0.116 +KVM: 0.099 +performance: 0.095 + +User-emu documentation mentions inexistent "runtime" downloads + +The official documentation for the user-space emulator[1] contains many references to binary blobs no longer provided by QEMU.org for download. The parts mentioning them should be rephrased to avoid confusion and instructions for building these components should be provided (maybe as a reference to the LFS book with some scripts). The specific parts are: + +* qemu-XXX-i386-wine.tar.gz, a wine build under the prefix /wine. +* qemu-runtime-i386-XXX-.tar.gz, a glibc build. + + [1]: https://www.qemu.org/docs/master/user/main.html + +In addition, the documentation contains many other instances of inexistent "tar.gz" files, such as in "Network emulation". Most of these are inherited from the days of texi documentation more than 10 years ago, and they are so old that GitHub's blame have become unreliable. Someone really should run `fgrep -r 'tar.gz' doc' on the QEMU source tree. + +The issue was previously reported as [2], but nobody bother enough to google the filename to find out where the confused user got the idea from. + + [2]: https://<email address hidden>/msg569174.html + +This patch removes the whole 'quick start' section from the user mode manual, including the references to the outdated tarballs: https://<email address hidden>/ + + +FWIW, seems like Peter's patch got included here: +https://gitlab.com/qemu-project/qemu/-/commit/5b30c53041d8f4c26ed3cf +... but I guess we still need a patch for the Networking section? + + +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/560 + + diff --git a/results/classifier/zero-shot/108/none/1884990 b/results/classifier/zero-shot/108/none/1884990 new file mode 100644 index 000000000..669ec9f85 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1884990 @@ -0,0 +1,35 @@ +graphic: 0.472 +device: 0.158 +semantic: 0.133 +other: 0.106 +performance: 0.103 +vnc: 0.057 +boot: 0.048 +debug: 0.041 +socket: 0.040 +network: 0.033 +permissions: 0.032 +PID: 0.030 +files: 0.019 +KVM: 0.018 + +Cirrus graphics results in monochrome colour depth at 640x480 resolution + +Recently we upgraded to a distribution that bundled QEMU 4.2.0. We were previously running on QEMU 3.0.0. When booting Windows 10 VMs on x86_64, users experienced slow, monochrome graphics and the resolution was restricted to 640x480. Reverting to the prior vgabios-cirrus.bin from the prior source tarball remediated the issue. + +An example QEMU command line is below, if needed: +/bin/qemu-system-x86_64 -vnc 0.0.0.0:100 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -machine pc-i440fx-4.2,accel=kvm,usb=off,dump-guest-core=off -cpu qemu64 -m 2048 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -no-user-config -nodefaults -hda test.raw & + +This seems to be the following SeaBIOS bug: +https://<email address hidden>/msg12271.html + +Ah, great catch! Yes, that does appear to be the issue+fix. Is QEMU planning on integrating the next release of SeaBIOS or fixing this as a one-off for now? + +Yes, the maintainer will likely get the submodule updated before the next release. + +This issue is still marked as unresolved almost 6 months later. Has the submodule been updated and merged into QEMU yet? + +The patch mentioned by Philippe ("vga: fix cirrus bios") has been included into QEMU via this commit here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=de15df5ead400b7c3d0cf2 +... which has been released as part of QEMU v5.1 already. Thus this issue should be fixed now. + diff --git a/results/classifier/zero-shot/108/none/1886793 b/results/classifier/zero-shot/108/none/1886793 new file mode 100644 index 000000000..bb8bf0719 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1886793 @@ -0,0 +1,398 @@ +permissions: 0.313 +network: 0.294 +graphic: 0.290 +performance: 0.250 +debug: 0.249 +other: 0.242 +files: 0.220 +device: 0.217 +KVM: 0.217 +semantic: 0.190 +vnc: 0.188 +boot: 0.165 +socket: 0.147 +PID: 0.125 + +"go install" command fails while running inside s390x docker container on x86_64 host using qemu + +Steps to reproduce the issue: + +Register x86_64 host with the latest qemu-user-static. +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes + +Build the following Docker Image using following Dockerfile.s390x using command docker build -t test/crossbuild:latest-s390x -f Dockerfile.s390x . + +Dockerfile.s390x + +FROM alpine:3.11 as qemu + +ARG QEMU_VERSION=5.0.0-2 +ARG QEMU_ARCHS="s390x" + +RUN apk --update add curl + +#Enable non-native runs on amd64 architecture hosts +RUN for i in ${QEMU_ARCHS}; do curl -L https://github.com/multiarch/qemu-user-static/releases/download/v${QEMU_VERSION}/qemu-${i}-static.tar.gz | tar zxvf - -C /usr/bin; done +RUN chmod +x /usr/bin/qemu-* + +FROM s390x/golang:1.14.2-alpine3.11 +MAINTAINER LoZ Open Source Ecosystem (https://www.ibm.com/developerworks/community/groups/community/lozopensource) + +ARG MANIFEST_TOOL_VERSION=v1.0.2 + +#Enable non-native builds of this image on an amd64 hosts. +#This must be the first RUN command in this file! +COPY --from=qemu /usr/bin/qemu-*-static /usr/bin/ + +#Install su-exec for use in the entrypoint.sh (so processes run as the right user) +#Install bash for the entry script (and because it's generally useful) +#Install curl to download glide +#Install git for fetching Go dependencies +#Install ssh for fetching Go dependencies +#Install mercurial for fetching go dependencies +#Install wget since it's useful for fetching +#Install make for building things +#Install util-linux for column command (used for output formatting). +#Install grep and sed for use in some Makefiles (e.g. pulling versions out of glide.yaml) +#Install shadow for useradd (it allows to use big UID) +RUN apk update && apk add --no-cache su-exec curl bash git openssh mercurial make wget util-linux tini file grep sed shadow +RUN apk upgrade --no-cache + +#Disable ssh host key checking +RUN echo 'Host *' >> /etc/ssh/ssh_config \ + && echo ' StrictHostKeyChecking no' >> /etc/ssh/ssh_config + +#Disable cgo so that binaries we build will be fully static. +ENV CGO_ENABLED=0 + +#Recompile the standard library with cgo disabled. This prevents the standard library from being +#marked stale, causing full rebuilds every time. +RUN go install -v std + +#Install glide +RUN go get github.com/Masterminds/glide +ENV GLIDE_HOME /home/user/.glide + +#Install dep +RUN go get github.com/golang/dep/cmd/dep + +#Install ginkgo CLI tool for running tests +RUN go get github.com/onsi/ginkgo/ginkgo + +#Install linting tools. +RUN wget -O - -q https://install.goreleaser.com/github.com/golangci/golangci-lint.sh | sh -s v1.20.0 +RUN golangci-lint --version + +#Install license checking tool. +RUN go get github.com/pmezard/licenses + +#Install tool to merge coverage reports. +RUN go get github.com/wadey/gocovmerge + +#Install CLI tool for working with yaml files +RUN go get github.com/mikefarah/yaml + +#Delete all the Go sources that were downloaded, we only rely on the binaries +RUN rm -rf /go/src/* + +#Install vgo (should be removed once we take Go 1.11) +RUN go get -u golang.org/x/vgo + +#Ensure that everything under the GOPATH is writable by everyone +RUN chmod -R 777 $GOPATH + +RUN curl -sSL https://github.com/estesp/manifest-tool/releases/download/${MANIFEST_TOOL_VERSION}/manifest-tool-linux-s390x > manifest-tool && \ + chmod +x manifest-tool && \ + mv manifest-tool /usr/bin/ + +COPY entrypoint.sh /usr/local/bin/entrypoint.sh +ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/entrypoint.sh"] + + + + +The build just hangs at RUN go install -v std + + + +Also, while running the same command inside s390x container on x86_64 host, error Illegal instruction (core dumped) is thrown. +Register x86_64 host with the latest qemu-user-static. +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes + +docker run -it -v /home/test/qemu-s390x-static:/usr/bin/qemu-s390x-static s390x/golang:1.14.2-alpine3.11 + +Inside s390x container: + +apk update && apk add --no-cache su-exec curl bash git openssh mercurial make wget util-linux tini file grep sed shadow +apk upgrade --no-cache + +#Disable ssh host key checking +echo 'Host *' >> /etc/ssh/ssh_config +echo ' StrictHostKeyChecking no' >> /etc/ssh/ssh_config + +#Disable cgo so that binaries we build will be fully static. +export CGO_ENABLED=0 + +#Recompile the standard library with cgo disabled. This prevents the standard library from being +#marked stale, causing full rebuilds every time. +go install -v std +Describe the results you re +This gives the following error: +Illegal instruction (core dumped) + + + +Environment: +x86_64 Ub18.04 4.15.0-101-generic Ubuntu SMP x86_64 GNU/Linux + +QEMU user static version: 5.0.0-2 + +Container application: Docker + +Client: Docker Engine - Community + Version: 19.03.11 + API version: 1.40 + Go version: go1.13.10 + Git commit: 42e35e61f3 + Built: Mon Jun 1 09:12:22 2020 + OS/Arch: linux/amd64 + Experimental: false + +Server: Docker Engine - Community + Engine: + Version: 19.03.11 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.10 + Git commit: 42e35e61f3 + Built: Mon Jun 1 09:10:54 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.2.13 + GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429 + runc: + Version: 1.0.0-rc10 + GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd + docker-init: + Version: 0.18.0 + GitCommit: fec3683 + +Additional information optionally: +When I build the same Dockerfile.s390x on an s390x machine, it is built successfully. + +One more thing which I tried: +I installed qemu on x86 Ubuntu host with apt-get install. +Extracted s390x go 1.14.2 binaries on the same. Ran the following commands: + +root:~ wget -q https://storage.googleapis.com/golang/go1.14.2.linux-s390x.tar.gz +root@:~# chmod ugo+r go1.14.2.linux-s390x.tar.gz +root@:~# rm -rf /usr/local/go /usr/bin/go +root@:~# tar -C /usr/local -xzf go1.14.2.linux-s390x.tar.gz +root@:~# ln -sf /usr/local/go/bin/go /usr/bin/ +root@:~# ln -sf /usr/local/go/bin/gofmt /usr/bin/ +root@:~# ln -sf /usr/bin/gcc /usr/bin/s390x-linux-gnu-gcc +root@:~# go version +/lib/ld64.so.1: No such file or directory +root@:~# qemu-s390x /usr/bin/go version +/lib/ld64.so.1: No such file or directory + +Could you try to reproduce the problem with the latest version of QEMU from git repo? + +Cloned qemu source code, checked out latest tag v5.0.0, built and installed the same on x86 Ubuntu host using "make" and "make install". + +root:~# qemu-s390x --version +qemu-s390x version 5.0.0 (v5.0.0-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + +root:~# wget -q https://storage.googleapis.com/golang/go1.14.2.linux-s390x.tar.gz +root:~# chmod ugo+r go1.14.2.linux-s390x.tar.gz +root:~# rm -rf /usr/local/go /usr/bin/go +root:~# tar -C /usr/local -xzf go1.14.2.linux-s390x.tar.gz +root:~# ln -sf /usr/local/go/bin/go /usr/bin/ +root:~# ln -sf /usr/local/go/bin/gofmt /usr/bin/ +root:~# ln -sf /usr/bin/gcc /usr/bin/s390x-linux-gnu-gcc +root:~# go version +-bash: /usr/bin/go: cannot execute binary file: Exec format error +root:~# qemu-s390x /usr/bin/go version +/lib/ld64.so.1: No such file or directory + + +If you install go directly in your host system you must also install the libraries of s390x somewhere (except if it statically linked). + +The easiest way to test this is to install debian chroot, with something like: + +Check binftm_misc is configured: + +# cat /proc/sys/fs/binfmt_misc/qemu-s390x +enabled +interpreter //qemu-s390x +flags: OC +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff + +Then you can install a debian sid system into a directory: + +# debootstrap --arch=s390x --foreign sid chroot-s390x/ +# cp .../qemu-s390x chroot-s390x/ +# sudo chroot chroot-s390x/ /debootstrap/debootstrap --second-stage + +And then you can use it with: + +# sudo chroot s390x-chroot/ +# uname -m +s390x +# apt install golang-go +... + +I will try the same and will report here soon. + +What about the issue with getting a go s390x environment inside and s390x container running on x86 host using qemu-user-static? (This problem is also mentioned in the main issue above. This is the ultimate target which needs to be achieved, I want to be able to build an s390x docker image with go installations inside on an x86 host, rest of the stuff I did for debugging purposes only) + +I ran the following commands: + +#apt install debootstrap +#debootstrap_dir=debootstrap +#debootstrap --arch=s390x --foreign sid "$debootstrap_dir" +#sudo mkdir -p "${debootstrap_dir}/usr/bin" +#sudo cp "$(which qemu-s390x-static)" "${debootstrap_dir}/usr/bin" +#sudo cp "$(which qemu-s390x)" "${debootstrap_dir}/usr/bin" + +All commands above were successful except below one: + +#sudo chroot "$debootstrap_dir" /debootstrap/debootstrap --second-stage +Gave following error: +W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.47_s390x.deb +W: See //debootstrap/debootstrap.log for details (possibly the package libgcc1 is at fault) + +Anyway, I proceeded: +# uname -m +s390x + +# apt install golang-go +Reading package lists... Done +Building dependency tree... Done +You might want to run 'apt --fix-broken install' to correct these. +The following packages have unmet dependencies: + dpkg : Conflicts: dpkg:none + dpkg:none : Conflicts: dpkg but 1.20.5 is to be installed + golang-go : Depends: golang-1.14-go but it is not going to be installed + Depends: golang-src (>= 2:1.14~2) but it is not going to be installed + libgcc1 : Depends: gcc-10-base (= 10.1.0-1) but 10.1.0-6+b1 is to be installed +E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). + +# apt --fix-broken install +Reading package lists... Done +Building dependency tree... Done +Correcting dependencies... Done +The following packages will be REMOVED: + dpkg:none libgcc1 +0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. +1 not fully installed or removed. +After this operation, 85.0 kB disk space will be freed. +Do you want to continue? [Y/n] y +perl: warning: Setting locale failed. +perl: warning: Please check that your locale settings: + LANGUAGE = (unset), + LC_ALL = (unset), + LANG = "en_US.UTF-8" + are supported and installed on your system. +perl: warning: Falling back to the standard locale ("C"). +/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory +/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory +/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory +dpkg: error: parsing file '/var/lib/dpkg/status' near line 3918 package 'dpkg': + duplicate value for 'Package' field +E: Sub-process dpkg --set-selections returned an error code (2) +E: Couldn't record the approved state changes as dpkg selection states + + + +Any update on this? +I tried the latest version of qemu-user-static, it still fails with the same error. + +Le 23/11/2020 à 12:03, Nirman Narang a écrit : +> Any update on this? +> I tried the latest version of qemu-user-static, it still fails with the same error. +> + +It works fine for me. Perhaps your chroot has been corrupted by your +previous attempts + + +Let me try again using the following commands on a fresh x86 host. + +#apt install debootstrap +#debootstrap_dir=debootstrap +#debootstrap --arch=s390x --foreign sid "$debootstrap_dir" +#sudo mkdir -p "${debootstrap_dir}/usr/bin" +#sudo cp "$(which qemu-s390x-static)" "${debootstrap_dir}/usr/bin" +#sudo cp "$(which qemu-s390x)" "${debootstrap_dir}/usr/bin"#sudo chroot "$debootstrap_dir" /debootstrap/debootstrap --second-stage + +Here is the output of the steps I tried: + +root@11:~# cat /proc/sys/fs/binfmt_misc/qemu-s390x +enabled +interpreter /usr/bin/qemu-s390x-static +flags: F +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff + + +debootstrap --arch=s390x --foreign sid chroot-s390x_dir + +cp -f /usr/bin/qemu-s390x-static /root/chroot-s390x_dir/usr/bin/ + +chmod +x /root/chroot-s390x_dir/usr/bin/qemu-s390x-static + +chroot chroot-s390x_dir /debootstrap/debootstrap --second-stage --verbose + +chroot chroot-s390x_dir/ + + +root@11:/# uname -a +Linux 4.15.0-123-generic #126-Ubuntu SMP Wed Oct 21 09:40:11 UTC 2020 s390x GNU/Linux + +Then tried to install the golang version mentioned below: +golang | 2:1.15~1 | http://deb.debian.org/debian sid/main s390x Packages + + +root@11:/# go version +Illegal instruction (core dumped) + +root@11:/# go version -v +Segmentation fault (core dumped) + +The error is the same as the one faced while implementing the s390x container using qemu-user-static on x86 machine with go install commands as mentioned in the main issue above. + +Any update on this? +Tried on fresh env, Illegal instruction (core dumped), and Segmentation fault (core dumped) errors are still thrown with go commands. + +Which qemu version do you end up using? "/usr/bin/qemu-s390x-static" *usually* refers to the one provided by your distro, not your custom build. + +FWIW, I just installed go under Fedora 32 (which uses a slightly older version of go): + +[root@atomic-00 ~]# uname -a +Linux atomic-00 5.8.11-200.fc32.s390x #1 SMP Wed Sep 23 13:36:15 UTC 2020 s390x s390x s390x GNU/Linux + +[root@atomic-00 ~]# go version +go version go1.14.13 linux/s390x +[root@atomic-00 ~]# go version -v +go version go1.14.13 linux/s390x + + +As Laurent also cannot reproduce, maybe double check the QEMU you end up using is the right one? + +Using latest greatest go from https://golang.org/dl/ + +[root@atomic-00 hello]# /usr/local/go/bin/go version +go version go1.15.7 linux/s390x + + +I used the command "docker run --rm --privileged multiarch/qemu-user-static --reset -p yes". +This pulls the latest one automatically. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/1887604 b/results/classifier/zero-shot/108/none/1887604 new file mode 100644 index 000000000..45f3c6ebc --- /dev/null +++ b/results/classifier/zero-shot/108/none/1887604 @@ -0,0 +1,81 @@ +socket: 0.489 +graphic: 0.301 +PID: 0.284 +performance: 0.284 +semantic: 0.282 +other: 0.253 +vnc: 0.252 +network: 0.220 +device: 0.208 +KVM: 0.189 +permissions: 0.145 +debug: 0.108 +boot: 0.080 +files: 0.055 + +Forward host UNIX socket to guest TCP port + +Hello. I've been racking my brain trying to work out if this is possible. + +I would like to be able to forward to a guest TCP port, via a host UNIX socket to avoid opening a TCP port on the host. For example: + +qemu-system-i386 [...] -nic user,hostfwd=unix:/path/to/socket-:22 + +and then connect to the VM like: + +ssh -o "ProxyCommand socat - unix-connect:/path/to/socket" user@0.0.0.0 + +QEMU, as versatile as it is, doesn't appreciate my intuited syntax "hostfwd=unix:...". It is also unhappy with: + +qemu-system-i386 [...] \ + -chardev socket,id=foo,path=/path/to/socket,server,nowait \ + -nic user,hostfwd=chardev:foo-:22 + +And: + +qemu-system-i386 [...] \ + -nic user \ + -chardev socket,id=foo,path=/path/to/socket,server,nowait \ + -chardev socket,id=foo,host=10.0.2.15,port=22 + +I already found out how to connect in the opposite direction, **from** guest TCP to host UNIX, via guestfwd -> cmd -> socat. So I feel like there ought to be a way. + +If this is not yet a feature I would like to request it, and if it is, please tell me how! + +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/347 + + diff --git a/results/classifier/zero-shot/108/none/1888165 b/results/classifier/zero-shot/108/none/1888165 new file mode 100644 index 000000000..04f56f9ac --- /dev/null +++ b/results/classifier/zero-shot/108/none/1888165 @@ -0,0 +1,36 @@ +device: 0.594 +graphic: 0.445 +semantic: 0.425 +network: 0.402 +vnc: 0.336 +debug: 0.319 +performance: 0.281 +socket: 0.247 +files: 0.240 +other: 0.214 +permissions: 0.206 +boot: 0.185 +PID: 0.118 +KVM: 0.051 + +loopz/loopnz clearing previous instruction's modified flags on cx -> 0 + +If you run QBasic in qemu, printing a double-type single-digit number will print an extra decimal point (e.g. PRINT CDBL(3) prints "3.") that does not appear when running on a real CPU (or on qemu with -enable-kvm). I tracked this down to the state of the status flags after a loopnz instruction. + +After executing a sequence like this in qemu: + + mov bx,1 + mov cx,1 + dec bx ; sets Z bit in flags +A: loopnz A ; should not modify flags + +Z is incorrectly clear afterwards. loopz does the same thing (but not plain loop). Interestingly, inserting pushf+popf after dec results in Z set, so loopnz/loopz does not always clear Z itself but is rather interfering with the previous instruction's flag setting. + +Version 5.1.0-rc0, x86-64 host. + + + + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3cb3a7720b01830abd5 + diff --git a/results/classifier/zero-shot/108/none/1888601 b/results/classifier/zero-shot/108/none/1888601 new file mode 100644 index 000000000..2b905902a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1888601 @@ -0,0 +1,331 @@ +KVM: 0.530 +other: 0.485 +performance: 0.460 +device: 0.455 +vnc: 0.452 +debug: 0.451 +socket: 0.451 +graphic: 0.435 +network: 0.431 +PID: 0.418 +permissions: 0.415 +boot: 0.404 +files: 0.404 +semantic: 0.400 + +QEMU v5.1.0-rc0/rc1 hang with nested virtualization + +We're running Kata Containers using QEMU and with v5.1.0rc0 and rc1 have noticed a problem at startup where QEMu appears to hang. We are not seeing this problem on our bare metal nodes and only on a VSI that supports nested virtualization. + +We unfortunately see nothing at all in the QEMU logs to help understand the problem and a hung process is just a guess at this point. + +Using git bisect we first see the problem with... + +--- + +f19bcdfedd53ee93412d535a842a89fa27cae7f2 is the first bad commit +commit f19bcdfedd53ee93412d535a842a89fa27cae7f2 +Author: Jason Wang <email address hidden> +Date: Wed Jul 1 22:55:28 2020 +0800 + + virtio-pci: implement queue_enabled method + + With version 1, we can detect whether a queue is enabled via + queue_enabled. + + Signed-off-by: Jason Wang <email address hidden> + Signed-off-by: Cindy Lu <email address hidden> + Message-Id: <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + Acked-by: Jason Wang <email address hidden> + + hw/virtio/virtio-pci.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- + +Reverting this commit seems to work and prevent the hanging. + +--- + +Here's how kata ends up launching qemu in our environment -- +/opt/kata/bin/qemu-system-x86_64 -name sandbox-849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f -uuid 6bec458e-1da7-4847-a5d7-5ab31d4d2465 -machine pc,accel=kvm,kernel_irqchip -cpu host,pmu=off -qmp unix:/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/qmp.sock,server,nowait -m 4096M,slots=10,maxmem=30978M -device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= -device virtio-serial-pci,disable-modern=true,id=serial0,romfile= -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/console.sock,server,nowait -device virtio-scsi-pci,id=scsi0,disable-modern=true,romfile= -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0,romfile= -device virtserialport,chardev=charch0,id=channel0,name=agent.channel.0 -chardev socket,id=charch0,path=/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/kata.sock,server,nowait -chardev socket,id=char-396c5c3e19e29353,path=/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/vhost-fs.sock -device vhost-user-fs-pci,chardev=char-396c5c3e19e29353,tag=kataShared,romfile= -netdev tap,id=network-0,vhost=on,vhostfds=3:4,fds=5:6 -device driver=virtio-net-pci,netdev=network-0,mac=52:ac:2d:02:1f:6f,disable-modern=true,mq=on,vectors=6,romfile= -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic -daemonize -object memory-backend-file,id=dimm1,size=4096M,mem-path=/dev/shm,share=on -numa node,memdev=dimm1 -kernel /opt/kata/share/kata-containers/vmlinuz-5.7.9-74 -initrd /opt/kata/share/kata-containers/kata-containers-initrd_alpine_1.11.2-6_agent.initrd -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 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=4 agent.use_vsock=false scsi_mod.scan=none init=/usr/bin/kata-agent -pidfile /run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/pid -D /run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/qemu.log -smp 2,cores=1,threads=1,sockets=4,maxcpus=4 + +--- + +Seems an odd one to be the culprit? Still lets ask Jason. +Can you just clarify; is this qemu 5.1.0-rc on both the host and the kata, or are you just changing to using qemu 5.1 as the host, and you're sticking with the existing kata qemu? + +Which host CPU have you got? + +I believe the VSI itself is QEMU based but don't know the version or details but suspect it's 4.1 based. We compile our own QEMU version for use with Kata and that's where we're now using 5.1.0-rc1 with the above commit reverted. + +Host Kernel is ... 4.15.0-101-generic if that helps + +re: cpu -- four of these... +``` +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 61 +model name : Intel Core Processor (Broadwell, IBRS) +stepping : 2 +microcode : 0x1 +cpu MHz : 2095.148 +cache size : 16384 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +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 mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc 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 cpuid_fault invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat md_clear +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit +bogomips : 4190.29 +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: +``` + + +Hi: + +It's not clear to me: + +- Is the hang happen on the host or L1 guest? +- Is qemu 5.1-rc0 used on the host or L1 guest? +- When did you see the hung, just after launching the guest? +- Can you use gdb to get a calltrace of qemu when you see the hang? +- What's the version of kernel in L1 and L2 guest? + +Thanks + +Simon: Please answer Jason's questions + +But my reading is; I don't know what a VSI is but I'm guessing it's the host and he doesn't know the host qemu; so the 5.1is the qemu that kata is running? + +It perhaps would make more sense if this has nothing to do with nesting, and more to do with Kata's virtio setup; I've just tried virtio-fs on current head (outside kata) and it seems OK from a quick test. + +:) Sorry a VSI is a virtual server instance e.g a VM vs. a bare metal server. + +I'm using IBM Cloud IKS which is a managed Kubernetes Service. I'm installing QEMU 5.1.x on the worker nodes. It is this instance of QEMU -- e.g. /opt/kata/bin/qemu-system-x86_64 -- that is hanging. The Kernel version at this level is... 4.15.0-101-generic. I don't know the QEMU or kernel version in the L0 host. + +FWIW the exact same setup with the identical OS, Kernel version, Kata runtime, QEMU etc. is working on a bare metal host. + + + +It hangs (still guessing here) immediately -- before anything is logged. I'll try to get you a calltrace but have to figure out how to do that first ;) Any pointers appreciated. + +Yon can get the calltrace by: + +1) compile the qemu with --enable-debug +2) using gdb -p $pid_of_qemu when you see the hang +3) thread apply all bt + +Thanks + +Thanks Jason, +Ok will do... gimme a day and I'll post what I see. + + +``` +(gdb) thread apply all bt + +Thread 5 (LWP 211759): +#0 0x00007ff56a9988d8 in g_str_hash () +#1 0x00007ff56a997a0c in g_hash_table_lookup () +#2 0x00007ff56a6c528f in type_table_lookup (name=0x7ff56ac9a9dd "virtio-bus") at qom/object.c:84 +#3 type_get_by_name (name=0x7ff56ac9a9dd "virtio-bus") at qom/object.c:171 +#4 object_class_dynamic_cast (class=class@entry=0x555556d92ac0, typename=typename@entry=0x7ff56ac9a9dd "virtio-bus") at qom/object.c:879 +#5 0x00007ff56a6c55b5 in object_class_dynamic_cast_assert (class=0x555556d92ac0, typename=typename@entry=0x7ff56ac9a9dd "virtio-bus", file=file@entry=0x7ff56aca60b8 "/root/qemu/hw/virtio/virtio.c", line=line@entry=3290, + func=func@entry=0x7ff56aca6c30 <__func__.31954> "virtio_queue_enabled") at qom/object.c:935 +#6 0x00007ff56a415842 in virtio_queue_enabled (vdev=0x555557ed9be0, n=0) at /root/qemu/hw/virtio/virtio.c:3290 +#7 0x00007ff56a5c0837 in vhost_net_start_one (dev=0x555557ed9be0, net=0x555556f99ca0) at hw/net/vhost_net.c:259 +#8 vhost_net_start (dev=dev@entry=0x555557ed9be0, ncs=0x555557eef030, total_queues=total_queues@entry=2) at hw/net/vhost_net.c:351 +#9 0x00007ff56a3f2d98 in virtio_net_vhost_status (status=<optimized out>, n=0x555557ed9be0) at /root/qemu/hw/net/virtio-net.c:268 +#10 virtio_net_set_status (vdev=0x555557ed9be0, status=<optimized out>) at /root/qemu/hw/net/virtio-net.c:349 +#11 0x00007ff56a413bdb in virtio_set_status (vdev=vdev@entry=0x555557ed9be0, val=val@entry=7 '\a') at /root/qemu/hw/virtio/virtio.c:1956 +#12 0x00007ff56a65bdf0 in virtio_ioport_write (val=7, addr=18, opaque=0x555557ed1a50) at hw/virtio/virtio-pci.c:331 +#13 virtio_pci_config_write (opaque=0x555557ed1a50, addr=18, val=<optimized out>, size=<optimized out>) at hw/virtio/virtio-pci.c:455 +#14 0x00007ff56a46eb2a in memory_region_write_accessor (attrs=..., mask=255, shift=<optimized out>, size=1, value=0x7ff463ffd5f8, addr=<optimized out>, mr=0x555557ed2340) at /root/qemu/softmmu/memory.c:483 +#15 access_with_adjusted_size (attrs=..., mr=0x555557ed2340, access_fn=<optimized out>, access_size_max=<optimized out>, access_size_min=<optimized out>, size=1, value=0x7ff463ffd5f8, addr=18) + at /root/qemu/softmmu/memory.c:544 +#16 memory_region_dispatch_write (mr=mr@entry=0x555557ed2340, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=..., attrs@entry=...) at /root/qemu/softmmu/memory.c:1465 +#17 0x00007ff56a3a94b2 in flatview_write_continue (fv=0x7ff45426a7c0, addr=addr@entry=53394, attrs=..., attrs@entry=..., ptr=ptr@entry=0x7ff5687eb000, len=len@entry=1, addr1=<optimized out>, l=<optimized out>, + mr=0x555557ed2340) at /root/qemu/include/qemu/host-utils.h:164 +#18 0x00007ff56a3adc4d in flatview_write (len=1, buf=0x7ff5687eb000, attrs=..., addr=53394, fv=<optimized out>) at /root/qemu/exec.c:3216 +#19 address_space_write (len=1, buf=0x7ff5687eb000, attrs=..., addr=53394, as=0x7ff5687eb000) at /root/qemu/exec.c:3307 +#20 address_space_rw (as=as@entry=0x7ff56b444d60 <address_space_io>, addr=addr@entry=53394, attrs=attrs@entry=..., buf=0x7ff5687eb000, len=len@entry=1, is_write=is_write@entry=true) at /root/qemu/exec.c:3317 +#21 0x00007ff56a3cdd5f in kvm_handle_io (count=1, size=1, direction=<optimized out>, data=<optimized out>, attrs=..., port=53394) at /root/qemu/accel/kvm/kvm-all.c:2262 +#22 kvm_cpu_exec (cpu=cpu@entry=0x555556ffaea0) at /root/qemu/accel/kvm/kvm-all.c:2508 +#23 0x00007ff56a46503c in qemu_kvm_cpu_thread_fn (arg=0x555556ffaea0) at /root/qemu/softmmu/cpus.c:1188 +#24 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x555556ffaea0) at /root/qemu/softmmu/cpus.c:1160 +#25 0x00007ff56a7d0f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#26 0x00007ff56ab95109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#27 0x00007ff56ac43353 in clone () + +Thread 4 (LWP 211758): +#0 0x00007ff56ac3eebb in ioctl () +#1 0x00007ff56a3cd98b in kvm_vcpu_ioctl (cpu=cpu@entry=0x555556fb4ac0, type=type@entry=44672) at /root/qemu/accel/kvm/kvm-all.c:2631 +#2 0x00007ff56a3cdac5 in kvm_cpu_exec (cpu=cpu@entry=0x555556fb4ac0) at /root/qemu/accel/kvm/kvm-all.c:2468 +#3 0x00007ff56a46503c in qemu_kvm_cpu_thread_fn (arg=0x555556fb4ac0) at /root/qemu/softmmu/cpus.c:1188 +#4 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x555556fb4ac0) at /root/qemu/softmmu/cpus.c:1160 +#5 0x00007ff56a7d0f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#6 0x00007ff56ab95109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#7 0x00007ff56ac43353 in clone () + +Thread 3 (LWP 211757): +#0 0x00007ff56ac3dd0f in poll () +#1 0x00007ff56a9aa5de in g_main_context_iterate.isra () at pthread_create.c:679 +#2 0x00007ff56a9aa963 in g_main_loop_run () at pthread_create.c:679 +#3 0x00007ff56a4a5b71 in iothread_run (opaque=opaque@entry=0x555556e0c800) at iothread.c:82 +#4 0x00007ff56a7d0f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#5 0x00007ff56ab95109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007ff56ac43353 in clone () + +Thread 2 (LWP 211752): +#0 0x00007ff56ac4007d in syscall () +#1 0x00007ff56a7d1e32 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /root/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait () at util/qemu-thread-posix.c:460 +#3 0x00007ff56a7dc0f2 in call_rcu_thread () at util/rcu.c:258 +#4 0x00007ff56a7d0f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#5 0x00007ff56ab95109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007ff56ac43353 in clone () + +Thread 1 (LWP 211751): +#0 __lll_lock_wait (futex=futex@entry=0x7ff56b447980 <qemu_global_mutex>, private=0) at lowlevellock.c:52 +#1 0x00007ff56ab97263 in __pthread_mutex_lock (mutex=mutex@entry=0x7ff56b447980 <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:80 +#2 0x00007ff56a7d1087 in qemu_mutex_lock_impl (mutex=0x7ff56b447980 <qemu_global_mutex>, file=0x7ff56adcf1e3 "util/main-loop.c", line=238) at util/qemu-thread-posix.c:79 +#3 0x00007ff56a466f8e in qemu_mutex_lock_iothread_impl (file=file@entry=0x7ff56adcf1e3 "util/main-loop.c", line=line@entry=238) at /root/qemu/softmmu/cpus.c:1782 +#4 0x00007ff56a7e909d in os_host_main_loop_wait (timeout=951196740) at util/main-loop.c:238 +#5 main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:516 +#6 0x00007ff56a47876e in qemu_main_loop () at /root/qemu/softmmu/vl.c:1676 +#7 0x00007ff56a3a5b52 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /root/qemu/softmmu/main.c:49 +``` + +Here's what I get with 5.1.0-rc2 + +``` +(gdb) thread apply all bt + +Thread 5 (LWP 23730): +#0 0x00007f9ae6040ebb in ioctl () +#1 0x00007f9ae57cf98b in kvm_vcpu_ioctl (cpu=cpu@entry=0x555557539ea0, type=type@entry=44672) at /root/qemu/accel/kvm/kvm-all.c:2631 +#2 0x00007f9ae57cfac5 in kvm_cpu_exec (cpu=cpu@entry=0x555557539ea0) at /root/qemu/accel/kvm/kvm-all.c:2468 +#3 0x00007f9ae586703c in qemu_kvm_cpu_thread_fn (arg=0x555557539ea0) at /root/qemu/softmmu/cpus.c:1188 +#4 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x555557539ea0) at /root/qemu/softmmu/cpus.c:1160 +#5 0x00007f9ae5bd2f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#6 0x00007f9ae5f97109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#7 0x00007f9ae6045353 in clone () + +Thread 4 (LWP 23729): +#0 0x00007f9ae5fed337 in __strcmp_sse2 () +#1 0x00007f9ae5d9a8ad in g_str_equal () at pthread_create.c:679 +#2 0x00007f9ae5d99a9d in g_hash_table_lookup () at pthread_create.c:679 +#3 0x00007f9ae5ac728f in type_table_lookup (name=0x7f9ae609c9dd "virtio-bus") at qom/object.c:84 +#4 type_get_by_name (name=0x7f9ae609c9dd "virtio-bus") at qom/object.c:171 +#5 object_class_dynamic_cast (class=class@entry=0x5555572d1ac0, typename=typename@entry=0x7f9ae609c9dd "virtio-bus") at qom/object.c:879 +#6 0x00007f9ae5ac75b5 in object_class_dynamic_cast_assert (class=0x5555572d1ac0, typename=typename@entry=0x7f9ae609c9dd "virtio-bus", file=file@entry=0x7f9ae60a80b8 "/root/qemu/hw/virtio/virtio.c", line=line@entry=3290, + func=func@entry=0x7f9ae60a8c30 <__func__.31954> "virtio_queue_enabled") at qom/object.c:935 +#7 0x00007f9ae5817842 in virtio_queue_enabled (vdev=0x555558418be0, n=0) at /root/qemu/hw/virtio/virtio.c:3290 +#8 0x00007f9ae59c2837 in vhost_net_start_one (dev=0x555558418be0, net=0x5555574d8ca0) at hw/net/vhost_net.c:259 +#9 vhost_net_start (dev=dev@entry=0x555558418be0, ncs=0x55555842e030, total_queues=total_queues@entry=2) at hw/net/vhost_net.c:351 +#10 0x00007f9ae57f4d98 in virtio_net_vhost_status (status=<optimized out>, n=0x555558418be0) at /root/qemu/hw/net/virtio-net.c:268 +#11 virtio_net_set_status (vdev=0x555558418be0, status=<optimized out>) at /root/qemu/hw/net/virtio-net.c:349 +#12 0x00007f9ae5815bdb in virtio_set_status (vdev=vdev@entry=0x555558418be0, val=val@entry=7 '\a') at /root/qemu/hw/virtio/virtio.c:1956 +#13 0x00007f9ae5a5ddf0 in virtio_ioport_write (val=7, addr=18, opaque=0x555558410a50) at hw/virtio/virtio-pci.c:331 +#14 virtio_pci_config_write (opaque=0x555558410a50, addr=18, val=<optimized out>, size=<optimized out>) at hw/virtio/virtio-pci.c:455 +#15 0x00007f9ae5870b2a in memory_region_write_accessor (attrs=..., mask=255, shift=<optimized out>, size=1, value=0x7f99dfffd5f8, addr=<optimized out>, mr=0x555558411340) at /root/qemu/softmmu/memory.c:483 +#16 access_with_adjusted_size (attrs=..., mr=0x555558411340, access_fn=<optimized out>, access_size_max=<optimized out>, access_size_min=<optimized out>, size=1, value=0x7f99dfffd5f8, addr=18) + at /root/qemu/softmmu/memory.c:544 +#17 memory_region_dispatch_write (mr=mr@entry=0x555558411340, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=..., attrs@entry=...) at /root/qemu/softmmu/memory.c:1465 +#18 0x00007f9ae57ab4b2 in flatview_write_continue (fv=0x7f99d007ef80, addr=addr@entry=53394, attrs=..., attrs@entry=..., ptr=ptr@entry=0x7f9ae43f1000, len=len@entry=1, addr1=<optimized out>, l=<optimized out>, + mr=0x555558411340) at /root/qemu/include/qemu/host-utils.h:164 +#19 0x00007f9ae57afc4d in flatview_write (len=1, buf=0x7f9ae43f1000, attrs=..., addr=53394, fv=<optimized out>) at /root/qemu/exec.c:3216 +#20 address_space_write (len=1, buf=0x7f9ae43f1000, attrs=..., addr=53394, as=0x7f9ae43f1000) at /root/qemu/exec.c:3307 +#21 address_space_rw (as=as@entry=0x7f9ae6846d60 <address_space_io>, addr=addr@entry=53394, attrs=attrs@entry=..., buf=0x7f9ae43f1000, len=len@entry=1, is_write=is_write@entry=true) at /root/qemu/exec.c:3317 +#22 0x00007f9ae57cfd5f in kvm_handle_io (count=1, size=1, direction=<optimized out>, data=<optimized out>, attrs=..., port=53394) at /root/qemu/accel/kvm/kvm-all.c:2262 +#23 kvm_cpu_exec (cpu=cpu@entry=0x5555574f3ac0) at /root/qemu/accel/kvm/kvm-all.c:2508 +#24 0x00007f9ae586703c in qemu_kvm_cpu_thread_fn (arg=0x5555574f3ac0) at /root/qemu/softmmu/cpus.c:1188 +#25 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x5555574f3ac0) at /root/qemu/softmmu/cpus.c:1160 +#26 0x00007f9ae5bd2f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#27 0x00007f9ae5f97109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#28 0x00007f9ae6045353 in clone () + +Thread 3 (LWP 23728): +#0 0x00007f9ae603fd0f in poll () +#1 0x00007f9ae5dac5de in g_main_context_iterate.isra () at pthread_create.c:679 +#2 0x00007f9ae5dac963 in g_main_loop_run () at pthread_create.c:679 +#3 0x00007f9ae58a7b71 in iothread_run (opaque=opaque@entry=0x55555734b800) at iothread.c:82 +#4 0x00007f9ae5bd2f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#5 0x00007f9ae5f97109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007f9ae6045353 in clone () + +Thread 2 (LWP 23723): +#0 0x00007f9ae604207d in syscall () +#1 0x00007f9ae5bd3e32 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /root/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait () at util/qemu-thread-posix.c:460 +#3 0x00007f9ae5bde0f2 in call_rcu_thread () at util/rcu.c:258 +#4 0x00007f9ae5bd2f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#5 0x00007f9ae5f97109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007f9ae6045353 in clone () +---Type <return> to continue, or q <return> to quit--- + +Thread 1 (LWP 23722): +#0 __lll_lock_wait (futex=futex@entry=0x7f9ae6849980 <qemu_global_mutex>, private=0) at lowlevellock.c:52 +#1 0x00007f9ae5f99263 in __pthread_mutex_lock (mutex=mutex@entry=0x7f9ae6849980 <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:80 +#2 0x00007f9ae5bd3087 in qemu_mutex_lock_impl (mutex=0x7f9ae6849980 <qemu_global_mutex>, file=0x7f9ae61d11e3 "util/main-loop.c", line=238) at util/qemu-thread-posix.c:79 +#3 0x00007f9ae5868f8e in qemu_mutex_lock_iothread_impl (file=file@entry=0x7f9ae61d11e3 "util/main-loop.c", line=line@entry=238) at /root/qemu/softmmu/cpus.c:1782 +#4 0x00007f9ae5beb09d in os_host_main_loop_wait (timeout=940584562) at util/main-loop.c:238 +#5 main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:516 +#6 0x00007f9ae587a76e in qemu_main_loop () at /root/qemu/softmmu/vl.c:1676 +#7 0x00007f9ae57a7b52 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /root/qemu/softmmu/main.c:49 +``` + + +Thanks for the information. + +It could be fixed by this commit upstream. + + +a48aaf882b100b30111b5c7c75e1d9e83fe76cfd ("virtio-pci: fix wrong index in virtio_pci_queue_enabled") + +Please try. + +Thanks + +Hi Jason, +See Comment#10 for trace -- 5.1.0-rc2 includes that fix... https://github.com/qemu/qemu/commit/a48aaf882b100b30111b5c7c75e1d9e83fe76cfd + +... so hang is still happening. + +Is there anything more I could do to help track this down? + +If even with that fix it's failing =and giving a similar back trace, then: + +Thread 4 (LWP 23729): +#0 0x00007f9ae5fed337 in __strcmp_sse2 () +#1 0x00007f9ae5d9a8ad in g_str_equal () at pthread_create.c:679 +#2 0x00007f9ae5d99a9d in g_hash_table_lookup () at pthread_create.c:679 +#3 0x00007f9ae5ac728f in type_table_lookup (name=0x7f9ae609c9dd "virtio-bus") at qom/object.c:84 +#4 type_get_by_name (name=0x7f9ae609c9dd "virtio-bus") at qom/object.c:171 +#5 object_class_dynamic_cast (class=class@entry=0x5555572d1ac0, typename=typename@entry=0x7f9ae609c9dd "virtio-bus") at qom/object.c:879 + +seems weird to me - why would you be stuck in a g_str_equal for any length of time (yet 2 of your backtraces both have it); yet the filename and symbol name don't really look like they're matching so I'm suspicious. +Have you got a minimal non-kata way to reproduce this? + + +Not currently, but let me try and setup just a simple qemu test + +This problem no longer occurs. I suspect it was an issue in my environment or possibly with the options I compiled QEMU with. This big/issue should be closed. + +er... This bug/issue should be closed. + + + diff --git a/results/classifier/zero-shot/108/none/1888818 b/results/classifier/zero-shot/108/none/1888818 new file mode 100644 index 000000000..46acbde27 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1888818 @@ -0,0 +1,102 @@ +semantic: 0.508 +other: 0.476 +permissions: 0.440 +debug: 0.434 +performance: 0.416 +KVM: 0.415 +graphic: 0.403 +device: 0.361 +network: 0.339 +PID: 0.321 +socket: 0.315 +files: 0.310 +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/zero-shot/108/none/1888971 b/results/classifier/zero-shot/108/none/1888971 new file mode 100644 index 000000000..ef4f97b8f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1888971 @@ -0,0 +1,53 @@ +device: 0.587 +debug: 0.583 +other: 0.419 +semantic: 0.372 +performance: 0.369 +graphic: 0.294 +boot: 0.288 +socket: 0.229 +PID: 0.221 +permissions: 0.161 +vnc: 0.144 +network: 0.124 +files: 0.122 +KVM: 0.072 + +SMI trigger causes hang with multiple cores + +When using qemu , SMI trigger causes hand/reboot under following conditions: + +1. No KVM but there are more than 1 threads (-smp > 1) +2. When using KVM. + +Info: +qemu-system-x86_64 --version +QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.29) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +SMI trigger was done by writing 0x00 in IO port 0xB2. + +Does coreboot do anything to set up an SMI handler? Does it relocate SMBASE for all processors? + +Misbehavior upon raising an SMI is fully expected, unless the guest (usually the guest firmware) sets up SMI handling properly. + +The bug report currently includes only two bits of information about guest actions, namely "coreboot.rom" and "writing 0x00 in IO port 0xB2". Thus far a guest crash looks entirely reasonable to me. + +Did you intend to attach "1.txt"? + +I tried without specifying -bios parameter still hang is seen. But this time it had low memory corruption. + +And built seabios with more debug logs but seabios doesn't does SMM init even when its selected in make menuconfig. + +I guess fundamentally th issue is writing 0xXX in IO port 0xB2 should trigger SMI handler in all possible core but instead it triggers SMI only in Core#0. + +> I guess fundamentally th issue is writing 0xXX in IO port 0xB2 should +> trigger SMI handler in all possible core but instead it triggers SMI +> only in Core#0. + +For that, the guest needs to negotiate the "broadcast SMI" feature with +QEMU. See commit range 57bb40c9db40..b8bab8eb6934. + + +Inactive for ~two weeks, closing. + diff --git a/results/classifier/zero-shot/108/none/1889288 b/results/classifier/zero-shot/108/none/1889288 new file mode 100644 index 000000000..a26bb478f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1889288 @@ -0,0 +1,28 @@ +semantic: 0.599 +graphic: 0.519 +other: 0.455 +device: 0.440 +permissions: 0.408 +socket: 0.381 +performance: 0.356 +vnc: 0.348 +network: 0.348 +files: 0.300 +debug: 0.270 +PID: 0.200 +boot: 0.182 +KVM: 0.137 + +aarch64 BICS instruciton doesn't set flags + +When reading the source for translate-a64.c here: + +https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783 + +I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug. + +The code is correct (though it is admittedly not entirely obvious at first glance). The switch statement at line 4753 is on "(opc | (invert << 2))" (where opc is a 2 bit field and invert a 1 bit field). Both ANDS and BICS have opc==3 and so will cause a call to gen_logic_CC(). The difference between the two insns is that ANDC has invert==0 and BICS has invert==1. + + +Oh yes I see. Sorry for the false report. + diff --git a/results/classifier/zero-shot/108/none/1890157 b/results/classifier/zero-shot/108/none/1890157 new file mode 100644 index 000000000..5f52afdda --- /dev/null +++ b/results/classifier/zero-shot/108/none/1890157 @@ -0,0 +1,56 @@ +device: 0.388 +graphic: 0.329 +files: 0.304 +vnc: 0.291 +PID: 0.240 +semantic: 0.200 +permissions: 0.195 +network: 0.187 +performance: 0.161 +boot: 0.089 +other: 0.083 +socket: 0.083 +KVM: 0.074 +debug: 0.071 + +Assertion failure in net_tx_pkt_reset through vmxnet3 + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x80001083 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +writeq 0xe0001020 0xefefff5ecafe0000 +writeq 0xe0001020 0xffff5e5ccafe0002 +EOF + +============================================================== +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/hw/net/net_tx_pkt.c:450: void net_tx_pkt_reset(struct NetTxPkt *): Assertion `pkt->raw' failed. + + #9 0x564838761930 in net_tx_pkt_reset /home/alxndr/Development/qemu/general-fuzz/hw/net/net_tx_pkt.c:450:5 + #10 0x564838881749 in vmxnet3_deactivate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1159:9 + #11 0x56483888cf71 in vmxnet3_reset /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1170:5 + #12 0x564838882124 in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1610:9 + #13 0x56483887f10f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9 + #14 0x56483738f193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 + #15 0x56483738e637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #16 0x56483738c256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 + #17 0x56483673d4a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + +-Alex + +This can still be reproduced with the current version of QEMU. Marking as "Confirmed" + +Fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/283f0a05e24a5e5fab783 + diff --git a/results/classifier/zero-shot/108/none/1890159 b/results/classifier/zero-shot/108/none/1890159 new file mode 100644 index 000000000..7b275b73a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1890159 @@ -0,0 +1,59 @@ +graphic: 0.564 +device: 0.312 +semantic: 0.229 +network: 0.164 +PID: 0.113 +performance: 0.110 +debug: 0.101 +permissions: 0.099 +boot: 0.056 +other: 0.048 +files: 0.037 +socket: 0.036 +vnc: 0.035 +KVM: 0.002 + +Assertion failure in net_tx_pkt_add_raw_fragment through vmxnet3 + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001010 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001001 +outl 0xcfc 0x3fff3fff +outl 0xcf8 0x80001016 +outl 0xcfc 0x5c84ff00 +outl 0xcf8 0x800010ff +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +writeq 0xff001020 0xef0bff5ecafe0000 +writel 0xe0000605 0xa7ff845e +EOF + +============================================================== +qemu-system-i386: hw/net/net_tx_pkt.c:382: _Bool net_tx_pkt_add_raw_fragment(struct NetTxPkt *, hwaddr, size_t): Assertion `pkt->max_raw_frags > pkt->raw_frags' failed. +Aborted + + +#9 0x5607db7efdc0 in net_tx_pkt_add_raw_fragment /home/alxndr/Development/qemu/general-fuzz/hw/net/net_tx_pkt.c:382:5 +#10 0x5607db902ef0 in vmxnet3_process_tx_queue /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:653:18 +#11 0x5607db9021db in vmxnet3_io_bar0_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1097:9 +#12 0x5607da41f193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 +#13 0x5607da41e637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +#14 0x5607da41c256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 +#15 0x5607d97cd4a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + +-Alex + +This still triggers with the current version of QEMU. Marking as "Confirmed" + +Looks like this was fixed by 283f0a05e2 ("hw/net/net_tx_pkt: Fix crash detected by fuzzer") + diff --git a/results/classifier/zero-shot/108/none/1890208 b/results/classifier/zero-shot/108/none/1890208 new file mode 100644 index 000000000..9c9d57ab3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1890208 @@ -0,0 +1,48 @@ +graphic: 0.445 +semantic: 0.391 +device: 0.298 +performance: 0.148 +vnc: 0.145 +socket: 0.121 +boot: 0.104 +PID: 0.099 +other: 0.093 +network: 0.085 +permissions: 0.055 +debug: 0.039 +files: 0.038 +KVM: 0.012 + +Mouse pointer disappears when it is over console window + +The host mouse pointer disappears when it is over a console window. + +I am emulating quite simple hardware: just text console and no mouse. I don't expect the mouse to have any effect on the emulated computers, but I need to know where the mouse pointer is. That is important because I need to use the mouse to switch between applications and to switch between virtual machines (QEMU grabs Alt+Tab events). Also, it is quite tricky to work with multiple screens when we don't know where the mouse pointer is. + +I am using: +* Virtual Machine Manager 2.2.1 +* QEMU 4.2.0 +* Fedora 32 +* KDE Plasma 5.18.5 + +Does your emulated machine have a graphics card (VGA or something similar)? If so, you might need to remove it from the guest. Also, have you tried to report this issue to the virt-manager project first? + +The emulated machine (guest) has the following graphics card, according to lspci: +00:01.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 04) + +The host machine has the following graphics card: +01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M1000M] (rev a2) + +I haven't tried to report the issue to virt-manager, but I have another computer running Debian with a similar setup and the problem does not happen there. + +I also reported this issue in: +https://github.com/virt-manager/virt-manager/issues/251 + + +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/434 + + diff --git a/results/classifier/zero-shot/108/none/1890310 b/results/classifier/zero-shot/108/none/1890310 new file mode 100644 index 000000000..2cef2db2e --- /dev/null +++ b/results/classifier/zero-shot/108/none/1890310 @@ -0,0 +1,67 @@ +other: 0.538 +graphic: 0.516 +permissions: 0.508 +vnc: 0.465 +network: 0.452 +PID: 0.449 +debug: 0.446 +KVM: 0.444 +performance: 0.442 +device: 0.432 +semantic: 0.400 +socket: 0.395 +files: 0.376 +boot: 0.357 + +Segfault in artist.c:block_move + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf8100802 0xff5c651ffffb7c5c +writeq 0xf8100afb 0x25e000000000000 +EOF + +AddressSanitizer:DEADLYSIGNAL +================================================================= +==12686==ERROR: AddressSanitizer: SEGV on unknown address 0x7f001a540000 (pc 0x55af3a373078 bp 0x7ffc23001a00 sp 0x7ffc23001670 T0) +==12686==The signal is caused by a READ memory access. + #0 0x55af3a373078 in block_move /hw/display/artist.c:525:13 + #1 0x55af3a365fbc in artist_reg_write /hw/display/artist.c:964:9 + #2 0x55af39a577a3 in memory_region_write_accessor /softmmu/memory.c:483:5 + #3 0x55af39a56adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #4 0x55af39a54873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 + #5 0x55af39102056 in flatview_write_continue /exec.c:3176:23 + #6 0x55af390ea866 in flatview_write /exec.c:3216:14 + #7 0x55af390ea387 in address_space_write /exec.c:3308:18 + #8 0x55af39afe604 in qtest_process_command /softmmu/qtest.c:452:13 + #9 0x55af39af5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #10 0x55af39af4895 in qtest_read /softmmu/qtest.c:722:5 + #11 0x55af3bfb0c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #12 0x55af3bfb0dc7 in qemu_chr_be_write /chardev/char.c:200:9 + #13 0x55af3bfc50b3 in fd_chr_read /chardev/char-fd.c:68:9 + #14 0x55af3c119474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #15 0x7f0028f60897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #16 0x55af3c51137b in glib_pollfds_poll /util/main-loop.c:217:9 + #17 0x55af3c50eaab in os_host_main_loop_wait /util/main-loop.c:240:5 + #18 0x55af3c50e444 in main_loop_wait /util/main-loop.c:516:11 + #19 0x55af39b16d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #20 0x55af3c151261 in main /softmmu/main.c:49:5 + #21 0x7f0027ae6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #22 0x55af38ff5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move +==12686==ABORTING + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex + +Fixed by commit a501bfc91763d4642390090dd4e6039d67b63702. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/108/none/1890311 b/results/classifier/zero-shot/108/none/1890311 new file mode 100644 index 000000000..45584e66b --- /dev/null +++ b/results/classifier/zero-shot/108/none/1890311 @@ -0,0 +1,68 @@ +other: 0.569 +graphic: 0.542 +vnc: 0.463 +permissions: 0.460 +debug: 0.436 +device: 0.430 +KVM: 0.416 +performance: 0.391 +semantic: 0.360 +PID: 0.318 +boot: 0.311 +files: 0.289 +network: 0.281 +socket: 0.266 + +Segfault in cpu_physical_memory_set_dirty_range on hppa + artist + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf810049f 0x85000000000000 +writew 0xf8118001 0x14 +writeq 0xf81005fb 0x5c00006418001832 +EOF + +AddressSanitizer:DEADLYSIGNAL +================================================================= +==10793==ERROR: AddressSanitizer: SEGV on unknown address 0x7f93dbb40000 (pc 0x5577f5523078 bp 0x7ffd41ad6360 sp 0x7ffd41ad5fd0 T0) +==10793==The signal is caused by a READ memory access. + + #0 0x5577f5523078 in block_move /hw/display/artist.c:525:13 + #1 0x5577f5515fbc in artist_reg_write /hw/display/artist.c:964:9 + #2 0x5577f4c077a3 in memory_region_write_accessor /softmmu/memory.c:483:5 + #3 0x5577f4c06adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #4 0x5577f4c04873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 + #5 0x5577f42b2056 in flatview_write_continue /exec.c:3176:23 + #6 0x5577f429a866 in flatview_write /exec.c:3216:14 + #7 0x5577f429a387 in address_space_write /exec.c:3308:18 + #8 0x5577f4cae604 in qtest_process_command /softmmu/qtest.c:452:13 + #9 0x5577f4ca5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #10 0x5577f4ca4895 in qtest_read /softmmu/qtest.c:722:5 + #11 0x5577f7160c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #12 0x5577f7160dc7 in qemu_chr_be_write /chardev/char.c:200:9 + #13 0x5577f71750b3 in fd_chr_read /chardev/char-fd.c:68:9 + #14 0x5577f72c9474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #15 0x7f93ea531897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #16 0x5577f76c137b in glib_pollfds_poll /util/main-loop.c:217:9 + #17 0x5577f76beaab in os_host_main_loop_wait /util/main-loop.c:240:5 + #18 0x5577f76be444 in main_loop_wait /util/main-loop.c:516:11 + #19 0x5577f4cc6d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #20 0x5577f7301261 in main /softmmu/main.c:49:5 + #21 0x7f93e90b7e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #22 0x5577f41a5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move +==10793==ABORTING + + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex + +Fixed in commit a501bfc91763d4642390090dd4e6039d67b63702 + diff --git a/results/classifier/zero-shot/108/none/1892960 b/results/classifier/zero-shot/108/none/1892960 new file mode 100644 index 000000000..8f22bfa90 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1892960 @@ -0,0 +1,344 @@ +other: 0.411 +device: 0.331 +KVM: 0.319 +socket: 0.290 +permissions: 0.272 +performance: 0.269 +semantic: 0.261 +boot: 0.250 +graphic: 0.250 +debug: 0.243 +vnc: 0.234 +PID: 0.188 +network: 0.186 +files: 0.185 + +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/zero-shot/108/none/1893744 b/results/classifier/zero-shot/108/none/1893744 new file mode 100644 index 000000000..995ca84e6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1893744 @@ -0,0 +1,142 @@ +vnc: 0.232 +permissions: 0.190 +KVM: 0.179 +debug: 0.162 +PID: 0.159 +other: 0.158 +semantic: 0.143 +device: 0.112 +graphic: 0.111 +socket: 0.111 +boot: 0.094 +performance: 0.094 +network: 0.089 +files: 0.083 + +meson: incomplete 'make help' + +Since the meson switch, 'make help' doesn't list various targets. + +Diff before/after: + +--- + Generic targets: + all - Build all + dir/file.o - Build specified target only + install - Install QEMU + ctags/TAGS - Generate tags file for editors + cscope - Generate cscope index +- +-Architecture specific targets: +- aarch64-softmmu/all - Build for aarch64-softmmu +- alpha-softmmu/all - Build for alpha-softmmu +- arm-softmmu/all - Build for arm-softmmu +- avr-softmmu/all - Build for avr-softmmu +- cris-softmmu/all - Build for cris-softmmu +- hppa-softmmu/all - Build for hppa-softmmu +- i386-softmmu/all - Build for i386-softmmu +- lm32-softmmu/all - Build for lm32-softmmu +- m68k-softmmu/all - Build for m68k-softmmu +- microblazeel-softmmu/all - Build for microblazeel-softmmu +- microblaze-softmmu/all - Build for microblaze-softmmu +- mips64el-softmmu/all - Build for mips64el-softmmu +- mips64-softmmu/all - Build for mips64-softmmu +- mipsel-softmmu/all - Build for mipsel-softmmu +- mips-softmmu/all - Build for mips-softmmu +- moxie-softmmu/all - Build for moxie-softmmu +- nios2-softmmu/all - Build for nios2-softmmu +- or1k-softmmu/all - Build for or1k-softmmu +- ppc64-softmmu/all - Build for ppc64-softmmu +- ppc-softmmu/all - Build for ppc-softmmu +- riscv32-softmmu/all - Build for riscv32-softmmu +- riscv64-softmmu/all - Build for riscv64-softmmu +- rx-softmmu/all - Build for rx-softmmu +- s390x-softmmu/all - Build for s390x-softmmu +- sh4eb-softmmu/all - Build for sh4eb-softmmu +- sh4-softmmu/all - Build for sh4-softmmu +- sparc64-softmmu/all - Build for sparc64-softmmu +- sparc-softmmu/all - Build for sparc-softmmu +- tricore-softmmu/all - Build for tricore-softmmu +- unicore32-softmmu/all - Build for unicore32-softmmu +- x86_64-softmmu/all - Build for x86_64-softmmu +- xtensaeb-softmmu/all - Build for xtensaeb-softmmu +- xtensa-softmmu/all - Build for xtensa-softmmu +- aarch64_be-linux-user/all - Build for aarch64_be-linux-user +- aarch64-linux-user/all - Build for aarch64-linux-user +- alpha-linux-user/all - Build for alpha-linux-user +- armeb-linux-user/all - Build for armeb-linux-user +- arm-linux-user/all - Build for arm-linux-user +- cris-linux-user/all - Build for cris-linux-user +- hppa-linux-user/all - Build for hppa-linux-user +- i386-linux-user/all - Build for i386-linux-user +- m68k-linux-user/all - Build for m68k-linux-user +- microblazeel-linux-user/all - Build for microblazeel-linux-user +- microblaze-linux-user/all - Build for microblaze-linux-user +- mips64el-linux-user/all - Build for mips64el-linux-user +- mips64-linux-user/all - Build for mips64-linux-user +- mipsel-linux-user/all - Build for mipsel-linux-user +- mips-linux-user/all - Build for mips-linux-user +- mipsn32el-linux-user/all - Build for mipsn32el-linux-user +- mipsn32-linux-user/all - Build for mipsn32-linux-user +- nios2-linux-user/all - Build for nios2-linux-user +- or1k-linux-user/all - Build for or1k-linux-user +- ppc64abi32-linux-user/all - Build for ppc64abi32-linux-user +- ppc64le-linux-user/all - Build for ppc64le-linux-user +- ppc64-linux-user/all - Build for ppc64-linux-user +- ppc-linux-user/all - Build for ppc-linux-user +- riscv32-linux-user/all - Build for riscv32-linux-user +- riscv64-linux-user/all - Build for riscv64-linux-user +- s390x-linux-user/all - Build for s390x-linux-user +- sh4eb-linux-user/all - Build for sh4eb-linux-user +- sh4-linux-user/all - Build for sh4-linux-user +- sparc32plus-linux-user/all - Build for sparc32plus-linux-user +- sparc64-linux-user/all - Build for sparc64-linux-user +- sparc-linux-user/all - Build for sparc-linux-user +- tilegx-linux-user/all - Build for tilegx-linux-user +- x86_64-linux-user/all - Build for x86_64-linux-user +- xtensaeb-linux-user/all - Build for xtensaeb-linux-user +- xtensa-linux-user/all - Build for xtensa-linux-user +- +-Helper targets: +- fsdev/virtfs-proxy-helper - Build virtfs-proxy-helper +- scsi/qemu-pr-helper - Build qemu-pr-helper +- qemu-bridge-helper - Build qemu-bridge-helper +- vhost-user-gpu - Build vhost-user-gpu +- virtiofsd - Build virtiofsd +- +-Tools targets: +- qemu-ga - Build qemu-ga tool +- qemu-keymap - Build qemu-keymap tool +- elf2dmp - Build elf2dmp tool +- ivshmem-client - Build ivshmem-client tool +- ivshmem-server - Build ivshmem-server tool +- qemu-nbd - Build qemu-nbd tool +- qemu-storage-daemon - Build qemu-storage-daemon tool +- qemu-img - Build qemu-img tool +- qemu-io - Build qemu-io tool +- qemu-edid - Build qemu-edid tool ++ sparse - Run sparse on the QEMU source + + Cleaning targets: + clean - Remove most generated files but keep +the config +@@ -105,7 +20,7 @@ + vm-help - Help about targets running tests +inside VM + + Documentation targets: +- html info pdf txt - Build documentation in specified format ++ html info pdf txt man - Build documentation in specified format + + make [targets] - (quiet build, default) + make V=1 [targets] - (verbose build) +--- + + +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/227 + + diff --git a/results/classifier/zero-shot/108/none/1895895 b/results/classifier/zero-shot/108/none/1895895 new file mode 100644 index 000000000..f1dad100a --- /dev/null +++ b/results/classifier/zero-shot/108/none/1895895 @@ -0,0 +1,63 @@ +device: 0.589 +files: 0.396 +PID: 0.325 +vnc: 0.294 +semantic: 0.282 +socket: 0.279 +other: 0.268 +graphic: 0.263 +boot: 0.203 +performance: 0.202 +permissions: 0.187 +network: 0.169 +debug: 0.161 +KVM: 0.023 + +Attaching SD-Card to specific SD-Bus Sabrelite (ARM) + +Currently, I am looking for a method of attaching an sd-card to a specific bus as opposed to defaulting to the first. + +QEMU Version: 5.0.0 +Specifically trying to use qemu-system-arm binary + + +Running an "info qtree" shows the output seen in the attached image. I have attempted multiple different combinations of arguments to attempt to get the sd-card to appear on the FOURTH sd-bus but no luck. The machine type being used is Sabrelite. It should be noted that I was able to PATCH QEMU to achieve the result I expected but I had hoped this functionality was already available and did not require modification to QEMU itself. + + +For reference, this is the patch that was made to source to allow the card to attach to a specific bus. After the change was made, an sd-card could be attached to a bus with the following flags: + +-drive file=sdcard.img,format=raw,id=mycard -device sd-card,drive=mycard,bus=sd-bus.0 + + +diff qemu-5.1.0.orig/hw/sd/sdhci.c qemu-5.1.0/hw/sd/sdhci.c +1311a1312,1314 +> static int index=0; +> char name[64]; +> sprintf(name, "sd-bus.%d", index++); +1313c1316 +< TYPE_SDHCI_BUS, DEVICE(s), "sd-bus"); +--- +> TYPE_SDHCI_BUS, DEVICE(s), name); + + + +If there is a way to attach an sd-card to the specific bus that does NOT require this change, I'd appreciate it. + + + +The fsl-imx* SoC devices need to create aliases onto the sd-buses with unique names; see discussion here: + + +https://lore.kernel.org<email address hidden>/ + +Patch sent: +https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05942.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/54 + + diff --git a/results/classifier/zero-shot/108/none/1897194 b/results/classifier/zero-shot/108/none/1897194 new file mode 100644 index 000000000..00f5856dd --- /dev/null +++ b/results/classifier/zero-shot/108/none/1897194 @@ -0,0 +1,62 @@ +performance: 0.480 +graphic: 0.460 +device: 0.450 +semantic: 0.440 +other: 0.415 +network: 0.413 +debug: 0.369 +permissions: 0.368 +PID: 0.301 +socket: 0.297 +boot: 0.245 +vnc: 0.237 +files: 0.179 +KVM: 0.132 + +Test failure in test-crypto-secret.c + +When running qemu test suite I'm seeing a test failure: + +ERROR:../qemu/tests/test-crypto-secret.c:144:test_secret_keyring_good: assertion failed: (key >= 0) + +Host is Arch Linux running in the standard Arch build environment (essentially an nspawn container). + +I first noticed this at release of 5.1.0 but it's still there on current trunk. For 5.1.0 I was able to sidestep the issue by building with `--disable-keyring' but this no longer works (I think due to 9866a33cbb7046891dec3dcc9ca2015828673afe) + +Any clues on what might be the cause? Not sure how to debug. + +Ping. Nobody else seeing this? + +I can only assume you don't have keyutils-dev (or equivalent) installed on your system. + +This is a key difference (pardon the pun!) between Arch and the bigger distros. Arch tends to avoid splitting development libs and headers into separate packages, which might explain why others are not seeing the test failure. + +strace shows the problem: + +add_key("user", "qemu_test_secret", "Test Payload", 12, KEY_SPEC_PROCESS_KEYRING) = -1 EPERM (Operation not permitted) + +It appears systemd-nspawn containers don't have CAP_SYS_ADMIN which is apparently needed for the keyring stuff to work. Fair enough. + +But the underlying problem here is configure switch `--disable-keyring' does not work. It previously worked in the 5.1.0 release but now it's broken. + + + +> systemd-nspawn containers don't have CAP_SYS_ADMIN + +Above statement is utter bollocks. Please ignore.. + + +I finally got to the bottom of all this and now have the test suite passing. + +- don't use `--disable-keyring', it's busted + +- systemd-nspawn containers need to be configured with additional capabilities/syscalls (see below) + +I noticed another test failing (postcopy-ram in tests/qtest/migration-test.c). It needs access to munlockall which is covered by CAP_IPC_LOCK capability. + +Here is my .nspawn config needed to get the test suite passing inside a systemd-nspawn container: + +[Exec] +Capability=CAP_IPC_LOCK +SystemCallFilter=add_key keyctl + diff --git a/results/classifier/zero-shot/108/none/1898084 b/results/classifier/zero-shot/108/none/1898084 new file mode 100644 index 000000000..dde2a3635 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1898084 @@ -0,0 +1,51 @@ +socket: 0.377 +network: 0.274 +boot: 0.217 +device: 0.180 +graphic: 0.149 +vnc: 0.149 +PID: 0.138 +performance: 0.115 +semantic: 0.090 +permissions: 0.088 +other: 0.086 +files: 0.076 +KVM: 0.054 +debug: 0.017 + +Assertion failed: (buf_len != 0), function soread, file socket.c, line 183. + +I have a virtual raspberry py that I am running qemu 5.1.0 for MacOS. + +Here is the command line I used: + +qemu-system-arm \ + -M versatilepb \ + -cpu arm1176 \ + -m 256 \ + -drive file=2020-08-20-raspios-buster-armhf-lite.img,if=none,index=0,media=disk,format=raw,id=disk0 \ + -device virtio-blk-pci,drive=disk0,disable-modern=on,disable-legacy=off \ + -net nic -net user,hostfwd=tcp::5022-:22 \ + -dtb versatile-pb-buster-5.4.51.dtb \ + -kernel kernel-qemu-5.4.51-buster \ + -append "root=/dev/vda2 panic=1" \ + -no-reboot \ + -serial stdio + +When trying to ssh from another machine while docker was running inside the VM, I got the following error: + +Assertion failed: (buf_len != 0), function soread, file /private/tmp/qemu-20200813-13289-1g95loa/qemu-5.1.0/slirp/src/socket.c, line 183 +../boot.sh: line 12: 8592 Abort trap: 6 + +libslirp is a separate project now, and I see that you already reported it there (https://gitlab.freedesktop.org/slirp/libslirp/-/issues/29), so I'm closing this QEMU ticket now. + +Hmm, thinking about it twice, maybe let's rather keep this open, to make sure that we update to the right version of libslirp in QEMU once the fix is released there. + + +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/284 + + diff --git a/results/classifier/zero-shot/108/none/1898883 b/results/classifier/zero-shot/108/none/1898883 new file mode 100644 index 000000000..934402005 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1898883 @@ -0,0 +1,63 @@ +device: 0.512 +other: 0.501 +permissions: 0.488 +performance: 0.456 +semantic: 0.441 +vnc: 0.407 +network: 0.379 +PID: 0.372 +graphic: 0.335 +socket: 0.315 +files: 0.314 +KVM: 0.276 +debug: 0.263 +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/zero-shot/108/none/1899082 b/results/classifier/zero-shot/108/none/1899082 new file mode 100644 index 000000000..fbacefdb5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1899082 @@ -0,0 +1,150 @@ +other: 0.570 +permissions: 0.484 +semantic: 0.475 +debug: 0.474 +boot: 0.474 +PID: 0.463 +KVM: 0.456 +graphic: 0.444 +device: 0.425 +performance: 0.422 +socket: 0.388 +vnc: 0.342 +files: 0.301 +network: 0.236 + +ReplayKernel.test_x86_64_pc fails intermittently + +Even though this acceptance test is already skipped on GitLab CI, the intermittent failures can be seen on other environments too. + +The record phase works fine, but during the replay phase fail to finish booting the kernel (until the expected place): + +16:34:47 DEBUG| [ 0.034498] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 +16:34:47 DEBUG| [ 0.034790] Spectre V2 : Spectre mitigation: LFENCE not serializing, switching to generic retpoline +16:34:47 DEBUG| [ 0.035093] Spectre V2 : Mitigation: Full generic retpoline +16:34:47 DEBUG| [ 0.035347] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +16:34:47 DEBUG| [ 0.035667] +16:36:02 ERROR| +16:36:02 ERROR| Reproduced traceback from: /home/cleber/src/avocado/avocado/avocado/core/test.py:767 +16:36:02 ERROR| Traceback (most recent call last): +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/replay_kernel.py", line 92, in test_x86_64_pc +16:36:02 ERROR| self.run_rr(kernel_path, kernel_command_line, console_pattern, shift=5) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/replay_kernel.py", line 73, in run_rr +16:36:02 ERROR| False, shift, args, replay_path) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/replay_kernel.py", line 55, in run_vm +16:36:02 ERROR| self.wait_for_console_pattern(console_pattern, vm) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/boot_linux_console.py", line 53, in wait_for_console_pattern +16:36:02 ERROR| vm=vm) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/avocado_qemu/__init__.py", line 130, in wait_for_console_pattern +16:36:02 ERROR| _console_interaction(test, success_message, failure_message, None, vm=vm) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/avocado_qemu/__init__.py", line 82, in _console_interaction +16:36:02 ERROR| msg = console.readline().strip() +16:36:02 ERROR| File "/usr/lib64/python3.7/socket.py", line 575, in readinto +16:36:02 ERROR| def readinto(self, b): +16:36:02 ERROR| File "/home/cleber/src/avocado/avocado/avocado/plugins/runner.py", line 77, in sigterm_handler +16:36:02 ERROR| raise RuntimeError("Test interrupted by SIGTERM") +16:36:02 ERROR| RuntimeError: Test interrupted by SIGTERM +16:36:02 ERROR| + +On my workstation, I can replicate the failure roughly once every 50 runs. + +I'm actually able to increase the reproducibility to ~ 90% when running 8 of those tests simultaneously (on an 8 core system). + +I can 100% reproduce it with the following command line: +taskset 1 tests/venv/bin/avocado --show=app,console,replay run -t arch:x86_64 ../tests/acceptance/replay_kernel.py + +But I can't reproduce it outside the avocado toolchain, by running qemu directly. + +I traced this bug to hw/char/serial.c/serial_ioport_read + +Bug disappears when I add qemu_log("serial_ioport_read %x %x\n", (int)addr, ret); into the end of this function. + +I suppose that there is avocado (or socket) io synchronization problem, because running the same test without avocado works normally. + +I could reproduce this without Avocado: + +-- +#!/bin/bash + +SOCKET="/tmp/qemu.sock" +VMLINUZ_PATH="/tmp/vmlinuz" +REPLAY_FILE="/tmp/replay.bin" + +function run_and_wait() { + /usr/bin/qemu-system-x86_64 -display none \ + -vga none \ + -machine pc \ + -chardev socket,id=console,path=${SOCKET},server=on,wait=off \ + -serial chardev:console \ + -icount shift=5,rr=$1,rrfile=${REPLAY_FILE} \ + -kernel ${VMLINUZ_PATH} \ + -append "printk.time=1 panic=-1 console=ttyS0" -net none -no-reboot & + # Wait a little for the socket creation + sleep 1 + socat - UNIX-CONNECT:${SOCKET} + echo $? +} + + +run_and_wait "record" +echo "Was this (record) finished?" + +run_and_wait "replay" +echo "Was this (replay) finished?" +-- + +The second echo is never displayed and my console stops here: + +--- +[ 0.036667] Speculative Store Bypass: Vulnerable +[ 0.256061] random: fast init done +[ 0.308652] Freeing SMP alternatives memory: 36K +--- + +I was able to run the reproducer from Beraldo Leal, and achieved the same results. + +Additionally, I got the following output from QEMU: + + qemu-system-x86_64: Missing character write event in the replay log + +Which seems to come from replay/replay-char.c:158. + +I then tested the record and replay separately, and found that, while the above message is given and QEMU exits at the replay phase, the amount of CPUs given to the *record* stage actually make the difference. When the recording is done with a single CPU, the replay log seems to be written with the "missing character write event". + +Beraldo, thanks for the script. +However, I can't reproduce the bug using it. I've got the newest QEMU from the repository, and it never hangs in this scenario. + +But there are some problems in other runs with more complex tasks. + +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/zero-shot/108/none/1899539 b/results/classifier/zero-shot/108/none/1899539 new file mode 100644 index 000000000..035b2ec1f --- /dev/null +++ b/results/classifier/zero-shot/108/none/1899539 @@ -0,0 +1,48 @@ +other: 0.436 +device: 0.436 +semantic: 0.385 +graphic: 0.291 +boot: 0.211 +files: 0.208 +PID: 0.182 +performance: 0.178 +debug: 0.157 +permissions: 0.150 +socket: 0.149 +vnc: 0.117 +network: 0.104 +KVM: 0.013 + +keyboard errors in DOS, found links to similar errors for reference + +OS: slackware 14.2, updated. qemu version: 4.1.0 (from slackbuild script) + +command line: qemu-system-i386 -hda msdos.vhd + +Description of problem: MSDOS 6.22 disk image running gwbasic 3.23. Cursor keys and sometimes letter keys are repeated. Cursor keys seemingly always, letter keys seem to happen when typing too fast. Numpad arrows are not affected. Also insert key doesnt seem to work at all. + +Have found one similar current bug, Bug #1574246 Drunken keyboard in go32v2 programs https://bugs.launchpad.net/qemu/+bug/1574246?comments=all and a much older vbox bug report that seems very similar, https://www.virtualbox.org/ticket/58 , and for some reason mentions a qemu patch. + +Also seems similar to https://bugs.launchpad.net/qemu/+bug/1897568 + +Could you please check whether the patch mentioned in https://bugs.launchpad.net/qemu/+bug/1897568 fixes this problem here, too? + +Which source version should I be applying that patch to? It's partially failing on 4.1.0, 5.0.0, and 6.0.0 + +Hmm, you likely need the whole patch series, and not only a single patch... + +If you've got a git checkout and b4 installed, you could try: + + b4 am <email address hidden> + git am ./v2_20210507_vr_qemu_ps_2_controller_related_fixes.mbx + +Otherwise it's maybe easier to wait until the patches have been merged... + + +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/292 + + diff --git a/results/classifier/zero-shot/108/none/1902 b/results/classifier/zero-shot/108/none/1902 new file mode 100644 index 000000000..172a2862d --- /dev/null +++ b/results/classifier/zero-shot/108/none/1902 @@ -0,0 +1,80 @@ +other: 0.274 +permissions: 0.185 +vnc: 0.169 +device: 0.161 +graphic: 0.134 +PID: 0.127 +performance: 0.099 +debug: 0.091 +semantic: 0.091 +KVM: 0.085 +boot: 0.082 +socket: 0.063 +network: 0.060 +files: 0.053 + +Crash on macOS when screen resolution changes when using SDL UI frontend +Description of problem: +In the above configuration, booting NetBSD works fine up to the point where the kernel sets the framebuffer resolution for the console, which results in a window size change. At this point, the OS terminates the qemu process with this error message: + +``` +*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow geometry should only be modified on the main thread!' +*** First throw call stack: +( + 0 CoreFoundation 0x00000001849208c0 __exceptionPreprocess + 176 + 1 libobjc.A.dylib 0x0000000184419eb4 objc_exception_throw + 60 + 2 CoreFoundation 0x0000000184945bac _CFBundleGetValueForInfoKey + 0 + 3 AppKit 0x00000001880a6ab8 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 240 + 4 AppKit 0x00000001880b2a38 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 88 + 5 AppKit 0x00000001880c18a0 -[NSTitledFrame _titleDidChange] + 116 + 6 AppKit 0x0000000188a92f04 -[NSTitledFrame setTitle:subtitle:] + 420 + 7 AppKit 0x00000001880c1570 -[NSThemeFrame setTitle:] + 52 + 8 AppKit 0x000000018866e0fc -[NSFrameView _updateTitleProperties:animated:] + 44 + 9 AppKit 0x0000000188a85e98 -[NSThemeFrame _updateTitleProperties:animated:] + 156 + 10 CoreFoundation 0x00000001848a0780 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 + 11 CoreFoundation 0x00000001849349a8 ___CFXRegistrationPost_block_invoke + 88 + 12 CoreFoundation 0x00000001849348f0 _CFXRegistrationPost + 440 + 13 CoreFoundation 0x000000018486f434 _CFXNotificationPost + 764 + 14 Foundation 0x0000000185960c74 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 + 15 AppKit 0x000000018881da88 -[NSWindowTitleController _propertiesChanged:] + 128 + 16 AppKit 0x00000001880c1388 -[NSWindow _dosetTitle:andDefeatWrap:] + 156 + 17 libSDL2-2.0.0.dylib 0x0000000106aa9abc Cocoa_SetWindowTitle + 104 + 18 qemu-system-aarch64 0x0000000105006628 sdl_update_caption + 256 + 19 qemu-system-aarch64 0x0000000105007838 sdl_mouse_mode_change + 168 + 20 qemu-system-aarch64 0x00000001054ab100 notifier_list_notify + 36 + 21 qemu-system-aarch64 0x0000000104d28124 qemu_input_check_mode_change + 96 + 22 qemu-system-aarch64 0x0000000104e13a74 hid_pointer_activate + 32 + 23 qemu-system-aarch64 0x0000000104f44c2c usb_process_one + 464 + 24 qemu-system-aarch64 0x0000000104f4491c usb_handle_packet + 120 + 25 qemu-system-aarch64 0x0000000104f58a94 xhci_kick_epctx + 1888 + 26 qemu-system-aarch64 0x00000001052d8f78 memory_region_write_accessor + 264 + 27 qemu-system-aarch64 0x00000001052d8db8 access_with_adjusted_size + 348 + 28 qemu-system-aarch64 0x00000001052d8c04 memory_region_dispatch_write + 428 + 29 qemu-system-aarch64 0x00000001052e6cfc flatview_write_continue + 344 + 30 qemu-system-aarch64 0x00000001052e4068 flatview_write + 156 + 31 qemu-system-aarch64 0x00000001052e9424 subpage_write + 124 + 32 qemu-system-aarch64 0x00000001052d8db8 access_with_adjusted_size + 348 + 33 qemu-system-aarch64 0x00000001052d8c04 memory_region_dispatch_write + 428 + 34 qemu-system-aarch64 0x000000010532ebf4 io_writex + 184 + 35 qemu-system-aarch64 0x000000010532ed44 do_st_mmio_leN + 104 + 36 qemu-system-aarch64 0x0000000105323e78 do_st4_mmu + 536 + 37 ??? 0x0000000108a91750 0x0 + 4440266576 + 38 qemu-system-aarch64 0x00000001053108f0 cpu_tb_exec + 164 + 39 qemu-system-aarch64 0x0000000105311754 cpu_exec_loop + 1084 + 40 qemu-system-aarch64 0x0000000105310edc cpu_exec_setjmp + 48 + 41 qemu-system-aarch64 0x0000000105310dcc cpu_exec + 560 + 42 qemu-system-aarch64 0x0000000105332650 tcg_cpus_exec + 44 + 43 qemu-system-aarch64 0x0000000105332c1c mttcg_cpu_thread_fn + 240 + 44 qemu-system-aarch64 0x00000001054a7494 qemu_thread_start + 128 + 45 libsystem_pthread.dylib 0x00000001847cf034 _pthread_start + 136 + 46 libsystem_pthread.dylib 0x00000001847c9e3c thread_start + 8 +) +libc++abi: terminating due to uncaught exception of type NSException +``` + +I think there have been other bugs of a similar nature in the past with the Cocoa UI. The regression may be because of stricter checks in the new macOS version. +Steps to reproduce: +1. Start qemu (the QEMU_EFI.fd is from Tianocore EDK2). +2. Wait for the NetBSD kernel to set framebuffer resolution and observe the crash. + +With `-nographic`, the problem does not occur. diff --git a/results/classifier/zero-shot/108/none/1908832 b/results/classifier/zero-shot/108/none/1908832 new file mode 100644 index 000000000..f8a9c88cc --- /dev/null +++ b/results/classifier/zero-shot/108/none/1908832 @@ -0,0 +1,269 @@ +permissions: 0.567 +PID: 0.494 +KVM: 0.490 +semantic: 0.442 +other: 0.420 +vnc: 0.409 +debug: 0.402 +device: 0.396 +graphic: 0.358 +network: 0.323 +performance: 0.321 +files: 0.293 +boot: 0.293 +socket: 0.184 + +jack audio dev produces no sound + +Hi, + +I'm testing the new jack audiodev backend in my +laptop. The host system is gentoo, using the +ebuild for qemu 5.1.0-r2, and I'm using jack +use flag globally in the system so any ebuild +that have support for jack should be build with +it. The jack setup reportedly works as I use it +with firefox, and mumble with no trouble. When +I launch the following script, I see the vm +connects to jack: + +/usr/bin/qemu-system-x86_64 -enable-kvm -M q35 -vga virtio -display gtk,gl=on \ + -cpu host -smp 2,cores=2,threads=1 \ + -m 4G -L /usr/share/qemu \ + -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \ + -drive file=/usr/share/edk2-ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ + -drive file=debian_VARS.fd,if=pflash,format=raw,unit=1 \ + -audiodev id=jack,driver=jack -device ich9-intel-hda -device hda-duplex,audiodev=jack \ + -device virtio-serial-pci \ + -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ + -chardev spicevmc,id=spicechannel0,name=vdagent \ + -device nec-usb-xhci,id=usb \ + -device usb-host,vendorid=0x04ca,productid=0x708e \ + -device usb-host,vendorid=0x1050,productid=0x0407 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev1 \ + -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev2 \ + -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev3 \ + -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 \ + -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \ + -drive file=debian.qcow2,cache=none,aio=io_uring,if=virtio + +Output of vm initialization: + +jack: JACK output configured for 48000Hz (1024 samples) +jack: JACK input configured for 48000Hz (1024 samples) +gl_version 46 - core profile enabled +GLSL feature level 430 + +Though executing any application that uses sound, +for instance, any youtube video through browser, +I listen nothing. By executing pkill jackd, and +launching the same script replacing the audiodev +line for the following: + + -audiodev id=alsa,driver=alsa -device ich9-intel-hda -device hda-duplex,audiodev=alsa \ + +The audio works, and I can listen to music, or +any other kind of application, though I cannot +listen anything else in the host. + +The guest is a simple debian testing(bullseye) +system with plasma desktop, using pulseaudio, +nothing fancy. + +Thanks! + +José + +Does this patch make a difference for you? +https://github.com/qemu/qemu/commit/a6e037390dd91276f4a631d41188c87e8a60bb3f + +If not, what's the precise JACK version you are using. + +I'm afraid it didn't. Jack version is: + +* media-sound/jack2 + Latest version available: 1.9.16 + Latest version installed: 1.9.16 + Size of files: 952 KiB + Homepage: https://jackaudio.org/ + Description: Jackdmp jack implemention for multi-processor machine + License: GPL-2 + +qemu config used in build: + +../configure --prefix=/usr --sysconfdir=/etc --bindir=/usr/bin --libdir=/usr/lib64 --datadir=/usr/share --docdir=/usr/share/doc/qemu-5.1.0-r2/html --mandir=/usr/share/man --with-confsuffix=/qemu --localstatedir=/var --disable-bsd-user --disable-containers --disable-guest-agent --disable-strip --disable-tcg-interpreter --disable-werror --disable-gcrypt --python=/usr/bin/python3.8 --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --host-cc=x86_64-pc-linux-gnu-gcc --disable-debug-info --disable-debug-tcg --disable-docs --disable-plugins --enable-attr --disable-brlapi --enable-linux-aio --enable-bzip2 --disable-capstone --enable-cap-ng --enable-curl --enable-fdt --disable-glusterfs --disable-gnutls --disable-nettle --enable-gtk --disable-rdma --disable-libiscsi --enable-linux-io-uring --disable-jemalloc --enable-vnc-jpeg --enable-kvm --disable-lzo --disable-mpath --enable-curses --disable-libnfs --disable-numa --enable-opengl --enable-vnc-png --disable-rbd --disable-vnc-sasl --enable-sdl --disable-sdl-image --enable-seccomp --enable-slirp=system --disable-smartcard --disable-snappy --enable-spice --disable-libssh --enable-libusb --enable-usb-redir --disable-vde --enable-vhost-net --disable-vhost-user-fs --enable-virglrenderer --disable-virtfs --enable-vnc --disable-vte --disable-xen --disable-xen-pci-passthrough --disable-xfsctl --enable-xkbcommon --disable-zstd --enable-libxml2 --audio-drv-list=jack,sdl,alsa,oss, --disable-linux-user --enable-system --disable-tools --target-list=aarch64-softmmu,arm-softmmu,riscv32-softmmu,riscv64-softmmu,x86_64-softmmu --enable-pie + +thanks! + +José. + +I unmasked qemu-5.2.0-r1, well, actually any newer qemu coming +from gentoo, and rebuild the software. The situation is still +reproducible, which confirms what I tested yesterday with the +patch. I also cleaned up the launch script to remove several +spice related unneeded since I use the gtk display, here is +how it looks like right now: + +/usr/bin/qemu-system-x86_64 -enable-kvm -M q35 -vga virtio -display gtk,gl=on \ + -cpu host -smp 4,cores=4,threads=1 \ + -m 2G -L /usr/share/qemu \ + -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \ + -drive file=/usr/share/edk2-ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ + -drive file=debian_VARS.fd,if=pflash,format=raw,unit=1 \ + -audiodev id=jack,driver=jack -device ich9-intel-hda -device hda-duplex,audiodev=jack \ + -device nec-usb-xhci,id=usb \ + -device usb-host,vendorid=0x04ca,productid=0x708e \ + -device usb-host,vendorid=0x1050,productid=0x0407 \ + -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \ + -drive file=debian.qcow2,cache=none,aio=io_uring,if=virtio + +Thanks! + +José. + +Hi, + +I spend some time debugging this during the morning, I found that there is a check +while connecting the ports that always exits the function without connecting the +jack ports, simplifying it as in the following diff lets me build and use the +audio outputs correctly in the vm: + +diff --git a/audio/jackaudio.c b/audio/jackaudio.c +index 3b7c18443d..f417e4db8a 100644 +--- a/audio/jackaudio.c ++++ b/audio/jackaudio.c +@@ -369,7 +369,7 @@ static size_t qjack_read(HWVoiceIn *hw, void *buf, size_t len) + + static void qjack_client_connect_ports(QJackClient *c) + { +- if (!c->connect_ports || !c->opt->connect_ports) { ++ if (!c->connect_ports) { + return; + } + +So, I wonder, what is this c->opt->connect_ports all about, is it needed, or just +wrongly initialized so that it caps the port connection? + +Thanks! + +Jose. + +just for completeness, this is how the output of the vm launch +looks like after the change: + +jack: connect out-(null):output 0 -> system:playback_1 +jack: connect out-(null):output 1 -> system:playback_2 +jack: JACK output configured for 48000Hz (1024 samples) +jack: connect system:capture_1 -> in-(null):input 0 +jack: connect system:capture_2 -> in-(null):input 1 +jack: JACK input configured for 48000Hz (1024 samples) +gl_version 46 - core profile enabled +GLSL feature level 430 + +And both input and output works as expected. + +Best regards. + +Jose. + +c->opt->connect_ports is an optional user supplied configuration argument which allows the user to specify a regular expression pattern which is used by QEMU's JACK audio driver to automatically connect its JACK ports to. From qapi/audio.json: + +## +# @AudiodevJackPerDirectionOptions: +# +# Options of the JACK backend that are used for both playback and +# recording. +# +# @server-name: select from among several possible concurrent server instances +# (default: environment variable $JACK_DEFAULT_SERVER if set, else "default") +# +# @client-name: the client name to use. The server will modify this name to +# create a unique variant, if needed unless @exact-name is true (default: the +# guest's name) +# +# @connect-ports: if set, a regular expression of JACK client port name(s) to +# monitor for and automatically connect to +# +# @start-server: start a jack server process if one is not already present +# (default: false) +# +# @exact-name: use the exact name requested otherwise JACK automatically +# generates a unique one, if needed (default: false) +# +# Since: 5.1 +## +{ 'struct': 'AudiodevJackPerDirectionOptions', + 'base': 'AudiodevPerDirectionOptions', + 'data': { + '*server-name': 'str', + '*client-name': 'str', + '*connect-ports': 'str', + '*start-server': 'bool', + '*exact-name': 'bool' } } + +I agree with you that it would be more user friendly to auto connect QEMU's output ports to system:playback_1, system:playback_2 and QEMU's input ports to system:capture_1, system:capture_2 respectively if the user did not specify any argument for "connect-ports". + +However I think your patch is a bit too simple, i.e. it is more or less luck that the system ports end up as the first two members in the lookup array "ports". It is working right now, but there is no guarantee about the order of the ports returned by jack_get_ports(): + +https://jackaudio.org/api/group__PortSearching.html + +So I would suggest changing your patch a bit by passing a lookup pattern like "system:playback_.*" to jack_get_ports() for QEMU output ports and a pattern like "system:capture_.*" for QEMU input ports, if c->opt->connect_ports is empty that is. + +Would you try to send a patch like this? And if yes, would you mind sending your patch directly to the qemu-devel mailing list? That would allow us to merge your patch more efficiently & quickly. + +https://wiki.qemu.org/Contribute/SubmitAPatch + +Yes, I agree, the patch itself is a quick fix, indeed, if I look to +the graphs in QJackCtl, I would expect to see new bubbles from qemu +connected to the system ports, as it happens when I connect Firefox +or Falkon through alsa -> jack plugin, as per the output you can +see it's using some sort of null sink already populated. + +About the patch, yes no problem I'll modify it and submit. + +Thanks! + +Jose. + +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. + + +Just for the records: the proposed patch was discussed on the QEMU mailing list, but there was no final consensus (yet) to accept the patch. Full discussion: + +https://<email address hidden>/msg785555.html + +It's probably Ok to let this report expire for now. If there are more users complaining about the current design of expecting the user to connect QEMU's JACK ports, then we can still go ahead with the patch. + +Ticket has been moved here (thanks, José!): +https://gitlab.com/qemu-project/qemu/-/issues/278 +... thus closing this on Launchpad now. + diff --git a/results/classifier/zero-shot/108/none/1909921 b/results/classifier/zero-shot/108/none/1909921 new file mode 100644 index 000000000..5ce8340d0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1909921 @@ -0,0 +1,115 @@ +permissions: 0.527 +other: 0.512 +debug: 0.498 +graphic: 0.479 +semantic: 0.470 +network: 0.443 +device: 0.418 +performance: 0.395 +boot: 0.352 +PID: 0.349 +files: 0.296 +socket: 0.295 +KVM: 0.258 +vnc: 0.189 + + Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e + +Hello, + +I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM Edition). +I created a CentOS 7 VM on it and I'm using a Docker container which is running qemu inside it. + +This container is a Debian Bullseye OS and I'm using qemu-i386 to start my application inside it. +The error given by qemu is the following : + +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff9d5f9b0e +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff82f29b0e + +(The pc= value is always different, I guess it is randomly generated). + +My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1) + +Could you please help me? Why am I facing this error? + +Feel free to ask any questions regarding this matter in order to find a solution to it! + +Regards + +What's the application you are trying to start? Is it publicly available? + +Hello, + +I'm trying to start a TeamSpeak 3 Server inside my Docker container. +Yes, this application is publicly available on the developer website and is free to install and use. + +Feel free to ask more question or test in other to resolve this matter. + +Thank you. + +Regards, + +Hello, + +Can I get any help please? + +Thank you. + +Regards, + +If you run QEMU with the '-d unimp' option (if that's awkward, set the environment variable QEMU_LOG to 'unimp' instead) does QEMU print any messages about unimplemented functionality? (In https://bugs.launchpad.net/qemu/+bug/1619896 somebody else was trying to run TeamSpeak 3 Server, which fails because of some unimplemented parts of the Linux syscall API in QEMU, but it doesn't actually crash apparently.) + + +Hello, + +If I do as mentionned this command: qemu-i386 -d unimp ./ts3server + +I get this output : + +2021-01-06 22:45:26.201997|INFO |ServerLibPriv | |TeamSpeak 3 Server 3.13.3 (2020-12-16 14:17:05) +2021-01-06 22:45:26.225836|INFO |ServerLibPriv | |SystemInformation: Linux 4.18.0-193.28.1.el7.aarch64 #1 SMP Wed Oct 21 16:25:35 UTC 2020 i686 Binary: 32bit +2021-01-06 22:45:26.227507|WARNING |ServerLibPriv | |The system locale is set to "C" this can cause unexpected behavior. We advice you to repair your locale! +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff81b99b0e +Trace/breakpoint trap (core dumped) + + +(Forget about the system local WARNING.) + +I attached the generated core dumps, if that helps. I don't have other logs to add. + +Thank you for your help! + +Regards, + + + + + + +If you can't see the core dumps, provide me with a file hoster where I can upload them. They are around 180mb each. + +Feel free to ask more test to find a solution to this matter. + +Thank you! + +Regards, + +Hello, + +I would really appreciate if anyone could confirm that someone is actually taking a look at this case. + +If you need more information / test, again feel free to ask! + +Regards, + +Hello, + +For you information using a Debian 10 distribution resolve the problem. +I don't know why but using a CentOS 7 distribution cause this error "qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff82f29b0e" + +You can close this case if you want, but still I guess it's worth investigating why this error is showing up while using CentOS rather than Debian ... + +Regards, + +Sorry, apparently nobody got a clue what might have gone wrong here (or simply not enough spare time to look at this issue), but since it's working for you now with a different distro, I'm closing this ticket now. + diff --git a/results/classifier/zero-shot/108/none/191 b/results/classifier/zero-shot/108/none/191 new file mode 100644 index 000000000..5587db449 --- /dev/null +++ b/results/classifier/zero-shot/108/none/191 @@ -0,0 +1,16 @@ +other: 0.492 +graphic: 0.454 +performance: 0.401 +device: 0.383 +semantic: 0.275 +debug: 0.175 +permissions: 0.131 +network: 0.077 +boot: 0.061 +files: 0.052 +vnc: 0.030 +PID: 0.028 +socket: 0.016 +KVM: 0.007 + +qemu64 CPU model is incorrect diff --git a/results/classifier/zero-shot/108/none/1917184 b/results/classifier/zero-shot/108/none/1917184 new file mode 100644 index 000000000..4bc1f7992 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1917184 @@ -0,0 +1,63 @@ +device: 0.504 +network: 0.492 +performance: 0.398 +graphic: 0.393 +socket: 0.393 +semantic: 0.376 +PID: 0.369 +KVM: 0.364 +files: 0.339 +other: 0.332 +vnc: 0.311 +debug: 0.286 +boot: 0.245 +permissions: 0.229 + +qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip + +When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault. + +qemu version 5.2.0, x86-64 host. + + + +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. + + +Bug still present in latest master + + +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/314 + + diff --git a/results/classifier/zero-shot/108/none/1920672 b/results/classifier/zero-shot/108/none/1920672 new file mode 100644 index 000000000..2b46fef76 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1920672 @@ -0,0 +1,79 @@ +other: 0.362 +socket: 0.326 +device: 0.312 +boot: 0.258 +graphic: 0.221 +semantic: 0.215 +vnc: 0.185 +PID: 0.176 +network: 0.146 +performance: 0.104 +permissions: 0.096 +debug: 0.083 +files: 0.068 +KVM: 0.031 + +Compilation fails with "ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)" + +It compiles until the end and then just: +[6102/6103] Linking target qemu-system-alpha +[6103/6103] Linking target qemu-system-aarch64 +make[1]: Leaving directory '/home/t/.cache/kiss/proc/32129/build/qemu/build' +make: *** [GNUmakefile:11: all] Error 2 + +Attached is the complete log including configure. I can't find why this is happening maybe I have a wrong version of a required library? + +Any ideas? + + + +This isn't silent: the log says: + + BUILD multiboot.img +ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) + +Which version of QEMU are you trying to build? Does this happen with head-of-git ? + + +I could not find +This is how it is configured: +./configure \ + --prefix=/usr \ + --localstatedir=/var \ + --sysconfdir=/etc \ + --enable-debug-info \ + --disable-gtk \ + --disable-docs \ + --enable-sdl \ + --enable-kvm \ + --enable-pie \ + --enable-curses \ + --disable-user \ + --disable-linux-user \ + --enable-system + +Version: 5.2.0 + +Also this: +$ grep "\-no\-pie" configure +# Check we support --no-pie first; we will need this for building ROMs. +if compile_prog "-Werror -fno-pie" "-no-pie"; then + LDFLAGS_NOPIE="-no-pie" + +Adding another hyphen is not helping either. + +I tried to comment out the whole block: +#if compile_prog "-Werror -fno-pie" "-no-pie"; then + # CFLAGS_NOPIE="-fno-pie" + # LDFLAGS_NOPIE="-no-pie" +#fi + +And it compiled and linked without any problem. + + + + +This is already fixed in upstream QEMU in commit bbd2d5a8120771, which will be in 6.0 and 5.2.1. + + + diff --git a/results/classifier/zero-shot/108/none/1920767 b/results/classifier/zero-shot/108/none/1920767 new file mode 100644 index 000000000..c1170e5fb --- /dev/null +++ b/results/classifier/zero-shot/108/none/1920767 @@ -0,0 +1,31 @@ +device: 0.405 +graphic: 0.341 +vnc: 0.297 +other: 0.290 +PID: 0.280 +network: 0.276 +semantic: 0.266 +socket: 0.222 +performance: 0.184 +files: 0.163 +KVM: 0.113 +permissions: 0.056 +boot: 0.014 +debug: 0.006 + +build-tools-and-docs-debian job waste cycles building pointless things + +The build-tools-and-docs-debian job waste CI cycles building softfloat: +https://gitlab.com/qemu-project/qemu/-/jobs/1117005759 + +Possible fix suggested on the list: +https://<email address hidden>/msg793872.html + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/229 + + diff --git a/results/classifier/zero-shot/108/none/1921635 b/results/classifier/zero-shot/108/none/1921635 new file mode 100644 index 000000000..9b8c7738e --- /dev/null +++ b/results/classifier/zero-shot/108/none/1921635 @@ -0,0 +1,174 @@ +KVM: 0.536 +other: 0.486 +vnc: 0.433 +debug: 0.360 +files: 0.345 +performance: 0.344 +graphic: 0.337 +device: 0.335 +semantic: 0.323 +PID: 0.321 +boot: 0.320 +permissions: 0.319 +network: 0.306 +socket: 0.299 + +ESP SCSI adapter not working with DOS ASPI drivers + +I have been trying to install the DOS ASPI drivers for the ESP scsi card. Both in am53c974 and dc390 modes. Neither works but they don't work in different ways. + +The following things appear to be problematic: + +* The am53c974 should work with the PcSCSI drivers (AMSIDA.SYS) but the ASPI driver never manages to get past initializing the card. The VM never continues. +* The dc390 ASPI driver fares a little better. The ASPI driver loads and is semi-functional but the drivers for the peripherals don't work. + - ASPI.SYS (creative name) loads + - TRMDISK.SYS fails to load when a cd-drive is attached and will crashs scanning the scsi-id where the cd drive is attached + - TRMDISK.SYS loads without a CD drive attached but fails to read any scsi-hd devices attached. The TFDISK.EXE formatter crashes. + - TRMCD.SYS loads, but can not detect any CD drives. + +The various permutations: +am53c974 hang on ASPI driver load: (CD only attached) + +~/src/qemu/build/qemu-system-i386 -m 64 -device am53c974,id=scsi0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda am53c974_aspi.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 crash because of CDROM attachment and loading TRMDISK.SYS (Only CD attached) +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 successful boot, but TRMDISK.SYS not working (TFDISK.EXE will crash) +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0 -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0,logical_block_size=512 -drive file=small.qcow2,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 successful boot, TRMDISK.SYS not loaded, only TRMCD.SYS. CDROM not detected +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_cd.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +All of these tests were done on 7b9a3c9f94bcac23c534bc9f42a9e914b433b299 as well as the 'esp-next' branch found here: https://github.com/mcayland/qemu/tree/esp-next + +The bios file is a seabios master with all int13 support disabled. With it enabled even less works but I figured this would be a seabios bug and not a qemu one. + +The actual iso and qcow2 files used don't appear the matter. the 'small.qcow2' is an empty drive of 100MB. I have also tried other ISOs in the CD drives, or even not put any cd in the drives with the same results. + +I will attach all of the above images. + + + + + + + + + + + +Something maybe worth noting is that the DC390 driver detectes attached CDROM drives as 'Fixed Disks' which seems a little fishy. The same appears to happen with the lsilogic card (that is cdrom drives get detected as hard drives and causes a failure to load the drivers) + +I've had a look at your am53c974 boot floppy with PcSCSI drivers and I'm fairly sure that disabling INT13 support isn't helping here. With your custom SeaBIOS I see a hang issuing the first SCSI command: without your custom SeaBIOS I can see that the default SeaBIOS issues several successful commands to the SCSI bus before booting from the floppy. + +Dropping the -bios option and booting your floppy here I see the following sequence with -trace 'scsi*' -trace 'esp*' after the BIOS has initialised: + + +esp_mem_writeb reg[3]: 0x42 -> 0x02 +esp_mem_writeb_cmd_reset Chip reset (0x02) +esp_mem_writeb reg[3]: 0x02 -> 0x80 +esp_mem_writeb_cmd_nop NOP (0x80) +esp_mem_writeb reg[11]: 0x00 -> 0x40 +esp_mem_readb reg[14]: 0x12 +esp_pci_sbac_read sbac: 0x00000000 +esp_pci_sbac_write sbac: 0x00000000 -> 0x02000000 +esp_mem_writeb reg[3]: 0x80 -> 0x02 +esp_mem_writeb_cmd_reset Chip reset (0x02) +esp_mem_writeb reg[3]: 0x02 -> 0x80 +esp_mem_writeb_cmd_nop NOP (0x80) +esp_mem_writeb reg[8]: 0x00 -> 0x17 +esp_mem_writeb reg[12]: 0x00 -> 0x88 +esp_mem_writeb reg[13]: 0x00 -> 0x40 +esp_mem_writeb reg[11]: 0x00 -> 0x40 +esp_mem_writeb reg[9]: 0x00 -> 0x07 +esp_mem_writeb reg[5]: 0x00 -> 0x8d +esp_mem_writeb reg[5]: 0x8d -> 0x02 +esp_mem_readb reg[8]: 0x17 +esp_mem_writeb reg[8]: 0x17 -> 0x07 +esp_mem_writeb reg[4]: 0x00 -> 0x00 +esp_mem_writeb reg[3]: 0x80 -> 0x01 +esp_mem_writeb_cmd_flush Flush FIFO (0x01) +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[3]: 0x01 -> 0x41 +esp_mem_writeb_cmd_sel Select without ATN (0x41) +esp_get_cmd len 6 target 0 +esp_do_busid_cmd busid 0x0 +scsi_req_parsed target 0 lun 0 tag 0 command 0 dir 0 length 0 +scsi_req_parsed_lba target 0 lun 0 tag 0 command 0 lba 0 +scsi_req_alloc target 0 lun 0 tag 0 +scsi_disk_new_request Command: lun=0 tag=0x0 data= 0x00 0x00 0x00 0x00 0x00 0x00 +scsi_test_unit_ready target 0 lun 0 tag 0 +scsi_req_dequeue target 0 lun 0 tag 0 +esp_command_complete SCSI Command complete +esp_raise_irq Raise IRQ +esp_lower_drq Lower DREQ + +****** +esp_pci_dma_read reg[5]: 0x00000018 +esp_mem_readb reg[4]: 0x93 +esp_mem_readb reg[6]: 0x00 +esp_lower_irq Lower IRQ +esp_mem_readb reg[5]: 0x18 +esp_mem_readb reg[8]: 0x07 +esp_mem_writeb reg[8]: 0x07 -> 0x47 +esp_mem_writeb reg[3]: 0x41 -> 0x03 +esp_mem_writeb_cmd_bus_reset Bus reset (0x03) +****** + + +The loading of the "test unit ready" command and execution look fine to me: QEMU's SCSI layer is executing the command (indicating success) and raises the ESP IRQ. However at this point in the section marked by "******" the ASPI driver seems not be happy with the RSTAT/RINTR register contents or the 0x18 read back from the PCI DMA registers, issues a bus reset and stops. + +What is interesting here is that the "Select without ATN (0x41)" command issued is a non-DMA command so I wouldn't expect it to affect the ESP PCI DMA register state, but I suspect you'll need to have a look what the driver is doing using a disassembler/gdbstub and the am53c974 datasheet to try and understand what is happening here. + +Finally it may be worth checking the IRQ routing with -trace 'pci*' to see if SeaBIOS updates the PCI "Interrupt Pin" register indicating where it thinks the IRQ should be routed, and stepping through the esp_raise_irq() in QEMU for the final test unit ready command to ensure that all of QEMU, SeaBIOS and AMSIDA.SYS all agree on what IRQ is being used. + +I'm looking at this document: http://bitsavers.trailing-edge.com/components/amd/_dataSheets/1993_53c974_PCscsi.pdf + +But I can't find this RSTAT/RINTR register in it. Am I looking at the wrong document, or is there a name mapping to the official names that I'm missing? + +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/569 + + diff --git a/results/classifier/zero-shot/108/none/1923497 b/results/classifier/zero-shot/108/none/1923497 new file mode 100644 index 000000000..853ad64c6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1923497 @@ -0,0 +1,139 @@ +other: 0.550 +KVM: 0.536 +vnc: 0.528 +graphic: 0.467 +permissions: 0.444 +boot: 0.439 +performance: 0.405 +PID: 0.403 +device: 0.397 +files: 0.376 +socket: 0.363 +semantic: 0.343 +network: 0.330 +debug: 0.312 + +bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed + +Trying boot/start a Windows 10 VM. Worked until recently when this error started showing up. + +I have the following installed on Fedora 33: +qemu-kvm-5.1.0-9.fc33.x86_64 + +This is the error: + +Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: /builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239: bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed. + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup + self._backend.create() + File "/usr/lib64/python3.9/site-packages/libvirt.py", line 1234, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirt.libvirtError: internal error: process exited while connecting to monitor: qemu-system-x86_64: /builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239: bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed. + +I see this were referenced in a patch from some time ago and supposedly fixed. Here is the patch info I was able to find: + +http://next.<email address hidden><email address hidden>/ + +On Mon, 12 Apr 2021 20:29:04 -0000 +Ed Davison <email address hidden> wrote: + +> Public bug reported: +> +> Trying boot/start a Windows 10 VM. Worked until recently when this +> error started showing up. +> +> I have the following installed on Fedora 33: +> qemu-kvm-5.1.0-9.fc33.x86_64 + +Could you add used QEMU command line in your case? + +> +> This is the error: +> +> Error starting domain: internal error: process exited while connecting +> to monitor: qemu-system-x86_64: /builddir/build/BUILD/qemu-5.1.0/hw/acpi +> /bios-linker-loader.c:239: bios_linker_loader_add_checksum: Assertion +> `start_offset < file->blob->len' failed. +> +> Traceback (most recent call last): +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper +> callback(asyncjob, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb +> callback(*args, **kwargs) +> File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn +> ret = fn(self, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup +> self._backend.create() +> File "/usr/lib64/python3.9/site-packages/libvirt.py", line 1234, in create +> if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +> libvirt.libvirtError: internal error: process exited while connecting to monitor: qemu-system-x86_64: /builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239: bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed. +> +> I see this were referenced in a patch from some time ago and supposedly +> fixed. Here is the patch info I was able to find: +> +> http://next.patchew.org/QEMU/1515677902-23436-1-git-send-email- +> <email address hidden>/1515677902-23436-10-git-send-email- +> <email address hidden>/ +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + + +Hmmm. Well, I don't know what the command line was. I use Virtual Machine Manager (virt-manager.org) for my interface to the VM and it does the startup. The error shows up when I start the VM. + + +On Tue, 13 Apr 2021 21:29:45 -0000 +Ed Davison <email address hidden> wrote: + +> Hmmm. Well, I don't know what the command line was. I use Virtual +> Machine Manager (virt-manager.org) for my interface to the VM and it +> does the startup. The error shows up when I start the VM. +In this case you should be able to attach domain xml. (View->Details->Overview->XML) + +Also try and see if the following patch helps: +https://<email address hidden>/T/#md70161e63276e9d5b6fd50fd835d2e62895810b8 + + + +The patch may be a bit beyond me at the moment as I use a package to install this and would have to figure out how to download source, get it configure, patched and compiled. Whew! Maybe ... + +But here is my XML config file. + +On Wed, 14 Apr 2021 19:40:36 -0000 +Ed Davison <email address hidden> wrote: + +> The patch may be a bit beyond me at the moment as I use a package to +> install this and would have to figure out how to download source, get it +> configure, patched and compiled. Whew! Maybe ... +> +> But here is my XML config file. +> +> ** Attachment added: "domain xml file" +> https://bugs.launchpad.net/qemu/+bug/1923497/+attachment/5487970/+files/win10-virt-domain.xml +> + +I don't see anything in this config that could trigger the assert. +(RAM size is 2Kb off 4Gb, but that's probably not the issue) + +Can you provide a stack trace, it should help to find out +which path triggers assert. + + + +Sorry, this has not recurred since you asked for the stack trace. Not sure what "fixed" it. Closing the bug. + +I guess I should say, you may close the bug. + +This was the fix: +https://gitlab.com/qemu-project/qemu/-/commit/bb9feea43179ef8aba2 + diff --git a/results/classifier/zero-shot/108/none/1929710 b/results/classifier/zero-shot/108/none/1929710 new file mode 100644 index 000000000..2e3429823 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1929710 @@ -0,0 +1,264 @@ +other: 0.415 +performance: 0.333 +graphic: 0.331 +KVM: 0.298 +semantic: 0.296 +debug: 0.286 +permissions: 0.264 +device: 0.261 +PID: 0.236 +network: 0.222 +files: 0.215 +boot: 0.212 +vnc: 0.191 +socket: 0.174 + +virDomainGetBlockJobInfo fails during swap_volume as disk '$disk' not found in domain + +Description +=========== + +The error handling around swap_volume is missing the following failure when calling virDomainGetBlockJobInfo() after the entire device is detached by QEMU (?) after it encounters a job during the block copy job that at first pauses and then somehow resumes the job: + +https://8a5fc27780098c5ee1bc-3ac81d180a9c011938b2cbb0293272f3.ssl.cf5.rackcdn.com/790660/5/gate/nova-next/e915ed4/controller/logs/screen-n-cpu.txt + +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver [None req-7cfcd661-29d4-4cc3-bc54-db0e7fed1a6e tempest-TestVolumeSwap-1841575704 tempest-TestVolumeSwap-1841575704-project-admin] Failure rebasing volume /dev/sdb on vdb.: libvirt.libvirtError: invalid argument: disk 'vdb' not found in domain +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver Traceback (most recent call last): +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2107, in _swap_volume +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver while not dev.is_job_complete(): +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 800, in is_job_complete +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver status = self.get_job_info() +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 707, in get_job_info +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver status = self._guest._domain.blockJobInfo(self._disk, flags=0) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 190, in doit +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver result = proxy_call(self._autowrap, f, *args, **kwargs) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 148, in proxy_call +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver rv = execute(f, *args, **kwargs) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 129, in execute +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver six.reraise(c, e, tb) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/six.py", line 719, in reraise +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver raise value +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 83, in tworker +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver rv = meth(*args, **kwargs) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/libvirt.py", line 985, in blockJobInfo +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver raise libvirtError('virDomainGetBlockJobInfo() failed') +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver libvirt.libvirtError: invalid argument: disk 'vdb' not found in domain +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver + +https://zuul.opendev.org/t/openstack/build/e915ed4aeb9346bba83910bd79e9502b/log/controller/logs/libvirt/libvirtd_log.txt + +2021-05-26 09:49:40.189+0000: 79419: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7fc4bc07e7d0 msg={"execute":"blockdev-add","arguments":{"node-name":"libvirt-4-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-4-storage"},"id":"libvirt-375"}^M + +2021-05-26 09:49:46.154+0000: 79422: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7fc4bc07e7d0 msg={"execute":"blockdev-add","arguments":{"node-name":"libvirt-5-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-5-storage"},"id":"libvirt-379"}^M + +2021-05-26 09:49:46.165+0000: 79422: debug : qemuMonitorBlockdevMirror:3112 : jobname=copy-vdb-libvirt-4-format, persistjob=1, device=libvirt-4-format, target=libvirt-5-format, bandwidth=0, granularity=0, buf_size=0, shallow=0 + +2021-05-26 09:49:46.167+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'created'(1) + +2021-05-26 09:49:46.167+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'running'(2) + +2021-05-26 09:49:46.763+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'paused'(3) + +2021-05-26 09:49:46.763+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'running'(2) + +2021-05-26 09:49:46.841+0000: 79417: debug : qemuProcessHandleDeviceDeleted:1362 : Device virtio-disk1 removed from domain 0x7fc4b416b0e0 instance-0000000b + +2021-05-26 09:49:47.457+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'aborting'(8) + +2021-05-26 09:49:47.458+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'concluded'(9) + +2021-05-26 09:49:47.459+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'null'(11) + + +Steps to reproduce +================== + +$ cat queries/virDomainGetBlockJobInfo.yaml +query: > + message:"virDomainGetBlockJobInfo() failed" AND + tags:"screen-n-cpu.txt" + +$ elastic-recheck-query queries/virDomainGetBlockJobInfo.yaml +total hits: 6 +build_branch + 100% master +build_change + 50% 786588 + 50% 792322 +build_hostids + 50% 1b47a855be51bba01ac6d5e6fdc4859bc17ebe2c8faaeb83392f8ff3 79fb0487675c0137b7ac30f24b5de71c70afb836e46746de770fa0c0 + 50% 33381c047c348ffefebf6b10cb7f0473c2359757d0bf11cc101eec54 33381c047c348ffefebf6b10cb7f0473c2359757d0bf11cc101eec54 +build_name + 100% nova-next +build_node + 100% ubuntu-focal +build_queue + 100% check +build_status + 100% FAILURE +build_zuul_url + 100% N/A +filename + 100% controller/logs/screen-n-cpu.txt +log_url + 50% https://89bc735e8a094e3d60b7-4f6db7cd5400cfa66e1c80fde6bd4076.ssl.cf1.rackcdn.com/792322/1/check/nova-next/de697b4/controller/logs/screen-n-cpu.txt + 50% https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_035/786588/6/check/nova-next/0357703/controller/logs/screen-n-cpu.txt +loglevel + 100% ERROR +module + 33% nova.compute.manager + 33% nova.virt.libvirt.driver + 33% oslo_messaging.rpc.server +node_provider + 50% ovh-bhs1 + 50% rax-iad +port + 50% 48014 + 50% 58238 +project + 100% openstack/nova +syslog_pid + 50% 107528 + 50% 108261 +syslog_program + 50% ubuntu-focal-ovh-bhs1-0024748800 nova-compute + 50% ubuntu-focal-rax-iad-0024745546 nova-compute +tags + 100% screen-n-cpu.txt screen oslofmt +voting + 100% 1 +zuul_attempts + 100% 1 +zuul_executor + 50% ze01.opendev.org + 50% ze07.opendev.org + + +Expected result +=============== +swap_volume at least fails correctly leaving the original device attached. + +Actual result +============= +swap_volume fails and the original device appears detached from the device. + +Environment +=========== +1. Exact version of OpenStack you are running. See the following + list for all releases: http://docs.openstack.org/releases/ + + master + +2. Which hypervisor did you use? + (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) + What's the version of that? + + libvirt + QEMU (no KVM in the gate) + +2. Which storage type did you use? + (For example: Ceph, LVM, GPFS, ...) + What's the version of that? + + images_type=default=qcow2 + +3. Which networking type did you use? + (For example: nova-network, Neutron with OpenVSwitch, ...) + + N/A + +Logs & Configs +============== + +Related fix proposed to branch: master +Review: https://review.opendev.org/c/openstack/nova/+/793219 + +I've added the QEMU project directly to this bug to see if anyone can help us understand what the underlying block job failure is within QEMU and why it then appears to remove the entire device from the instance causing libvirt and Nova to fallover. + +Just a note that the QEMU project is moving their bug tracking to gitlab [1] and will automatically migrate launchpad bugs, but it might be more expedient to open an issue on their gitlab tracker. + +[1] https://bugs.launchpad.net/qemu/+bug/1914282/comments/3 + +Reviewed: https://review.opendev.org/c/openstack/nova/+/793219 +Committed: https://opendev.org/openstack/nova/commit/d5ed968826895d362f4f2aa21decfdebb9b1fd84 +Submitter: "Zuul (22348)" +Branch: master + +commit d5ed968826895d362f4f2aa21decfdebb9b1fd84 +Author: Lee Yarwood <email address hidden> +Date: Wed May 26 19:27:45 2021 +0100 + + zuul: Skip swap_volume tests as part of nova-next + + The volume update or swap_volume API has long been a source of gate + failures within Nova. Most recently we've seen increased instability + when running the temptest.api.compute.admin.test_volume_swap tests as + part of the nova-next job as documented in bug #1929710. + + This change temporarily removes the failing test from the nova-next job + while the underlying issue is identified lower in the virt stack. + + Change-Id: Ib56a034fb08e309981d0b4553b8cee8d16b10152 + Related-Bug: #1929710 + + + + +QEMU issue opened for this bug is at https://gitlab.com/qemu-project/qemu/-/issues/287 + +This problem was reproduced in CI for one of my stable/wallaby patches: +https://zuul.opendev.org/t/openstack/build/3ae58b4f95d7442fb9110c4044acee2b/logs +https://1f24fdc3bf9479288b3a-225501c9cce0e8ba4bd0f4849071211d.ssl.cf1.rackcdn.com/888333/1/check/nova-next/3ae58b4/compute1/logs/libvirt/qemu/instance-00000011_log.txt +https://1f24fdc3bf9479288b3a-225501c9cce0e8ba4bd0f4849071211d.ssl.cf1.rackcdn.com/888333/1/check/nova-next/3ae58b4/compute1/logs/libvirt/libvirtd_log.txt +https://1f24fdc3bf9479288b3a-225501c9cce0e8ba4bd0f4849071211d.ssl.cf1.rackcdn.com/888333/1/check/nova-next/3ae58b4/compute1/logs/screen-n-cpu.txt +https://1f24fdc3bf9479288b3a-225501c9cce0e8ba4bd0f4849071211d.ssl.cf1.rackcdn.com/888333/1/check/nova-next/3ae58b4/job-output.txt + +Extracts: + + +Jul 13 08:35:22.230036 np0034667036 nova-compute[54149]: WARNING nova.virt.libvirt.driver [None req-7222880d-af15-4a90-b16d-24bdf5763e09 None None] Received event <DeviceRemovedEvent: 1689237322.2269797, dd46f9ba-2352-4da6-be3a-ecf68757e3c0 => virtio-disk1> from libvirt but the driver is not waiting for it; ignored. +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver [None req-473da26b-0641-4cda-84ef-9e451e5eddb9 tempest-TestVolumeSwap-869256485 tempest-TestVolumeSwap-869256485-project-admin] Failure rebasing volume /dev/sda on vdb.: libvirt.libvirtError: invalid argument: disk 'vdb' not found in domain +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver Traceback (most recent call last): +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2128, in _swap_volume +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver while not dev.is_job_complete(): +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 810, in is_job_complete +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver status = self.get_job_info() +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 717, in get_job_info +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver status = self._guest._domain.blockJobInfo(self._disk, flags=0) +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 190, in doit +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver result = proxy_call(self._autowrap, f, *args, **kwargs) +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 148, in proxy_call +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver rv = execute(f, *args, **kwargs) +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 129, in execute +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver six.reraise(c, e, tb) +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/six.py", line 703, in reraise +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver raise value +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 83, in tworker +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver rv = meth(*args, **kwargs) +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver File "/usr/lib/python3/dist-packages/libvirt.py", line 898, in blockJobInfo +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver if ret is None: raise libvirtError ('virDomainGetBlockJobInfo() failed', dom=self) +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver libvirt.libvirtError: invalid argument: disk 'vdb' not found in domain +Jul 13 08:35:22.242368 np0034667036 nova-compute[54149]: ERROR nova.virt.libvirt.driver + +2023-07-13 08:35:22.226+0000: 44724: debug : qemuMonitorEmitEvent:1198 : mon=0x7f6bcc07b080 event=DEVICE_DELETED +2023-07-13 08:35:22.226+0000: 44724: debug : qemuProcessHandleEvent:551 : vm=0x7f6bbc0b6db0 +2023-07-13 08:35:22.226+0000: 44724: debug : virObjectEventNew:631 : obj=0x55ea304db760 +2023-07-13 08:35:22.226+0000: 44724: debug : qemuMonitorJSONIOProcessEvent:205 : handle DEVICE_DELETED handler=0x7f6bc1e3db80 data=0x55ea304ad810 +2023-07-13 08:35:22.226+0000: 44724: debug : qemuMonitorEmitDeviceDeleted:1432 : mon=0x7f6bcc07b080 +2023-07-13 08:35:22.226+0000: 44724: debug : qemuProcessHandleDeviceDeleted:1364 : Device virtio-disk1 removed from domain 0x7f6bbc0b6db0 instance-00000011 +2023-07-13 08:35:22.226+0000: 44724: debug : virObjectEventDispose:124 : obj=0x55ea304db760 +2023-07-13 08:35:22.226+0000: 57688: debug : qemuProcessEventHandler:4866 : vm=0x7f6bbc0b6db0, event=2 +2023-07-13 08:35:22.226+0000: 57688: debug : processDeviceDeletedEvent:4282 : Removing device virtio-disk1 from domain 0x7f6bbc0b6db0 instance-00000011 +2023-07-13 08:35:22.226+0000: 57688: debug : qemuDomainObjBeginJobInternal:9416 : Starting job: job=modify agentJob=none asyncJob=none (vm=0x7f6bbc0b6db0 name=instance-00000011, current job=none agentJob=none async=none) +2023-07-13 08:35:22.226+0000: 57688: debug : qemuDomainObjBeginJobInternal:9470 : Started job: modify (async=none vm=0x7f6bbc0b6db0 name=instance-00000011) +2023-07-13 08:35:22.226+0000: 57688: debug : qemuDomainRemoveDiskDevice:4218 : Removing disk virtio-disk1 from domain 0x7f6bbc0b6db0 instance-00000011 +2023-07-13 08:35:22.226+0000: 57688: debug : qemuDomainObjEnterMonitorInternal:9869 : Entering monitor (mon=0x7f6bcc07b080 vm=0x7f6bbc0b6db0 name=instance-00000011) +2023-07-13 08:35:22.226+0000: 57688: debug : qemuDomainObjExitMonitorInternal:9892 : Exited monitor (mon=0x7f6bcc07b080 vm=0x7f6bbc0b6db0 name=instance-00000011) +2023-07-13 08:35:22.226+0000: 57688: debug : virObjectEventNew:631 : obj=0x7f6b80029ba0 +2023-07-13 08:35:22.226+0000: 44724: debug : virObjectEventDispose:124 : obj=0x7f6b80029ba0 +2023-07-13 08:35:22.227+0000: 57688: debug : qemuDomainObjEndJob:9746 : Stopping job: modify (async=none vm=0x7f6bbc0b6db0 name=instance-00000011) +2023-07-13 08:35:22.233+0000: 44727: debug : virThreadJobSet:93 : Thread 44727 (virNetServerHandleJob) is now running job remoteDispatchDomainGetBlockJobInfo +2023-07-13 08:35:22.233+0000: 44727: debug : qemuDomainObjBeginJobInternal:9416 : Starting job: job=query agentJob=none asyncJob=none (vm=0x7f6bbc0b6db0 name=instance-00000011, current job=none agentJob=none async=none) +2023-07-13 08:35:22.233+0000: 44727: debug : qemuDomainObjBeginJobInternal:9470 : Started job: query (async=none vm=0x7f6bbc0b6db0 name=instance-00000011) +2023-07-13 08:35:22.233+0000: 44727: error : qemuDomainDiskByName:13629 : invalid argument: disk 'vdb' not found in domain +2023-07-13 08:35:22.233+0000: 44727: debug : qemuDomainObjEndJob:9746 : Stopping job: query (async=none vm=0x7f6bbc0b6db0 name=instance-00000011) + diff --git a/results/classifier/zero-shot/108/none/1932 b/results/classifier/zero-shot/108/none/1932 new file mode 100644 index 000000000..febe59116 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1932 @@ -0,0 +1,27 @@ +device: 0.520 +graphic: 0.424 +other: 0.147 +semantic: 0.124 +debug: 0.091 +PID: 0.075 +performance: 0.068 +vnc: 0.053 +socket: 0.049 +boot: 0.044 +network: 0.042 +permissions: 0.007 +KVM: 0.006 +files: 0.006 + +Broken grab on hover setting +Description of problem: +It seems that now qemu implements "static" grab on hover, i.e., it can only be disabled by + +1. setting `vmport=off` in `-M` (btw, `pc` or `q35`, doesn't matter) +2. emulating a usb mouse *and* blacklist/unload the `psmouse` driver on the guest side + +while grab on hover setting in the gtk display backend (or frontend?) is seemingly bogus now either way. + +Can this be fixed (again?) so that the setting (which can be toggled in the menu "dynamically") can be used to tell this "vmport" thing whether or not it should grab on hover? +Additional information: +NIL diff --git a/results/classifier/zero-shot/108/none/1968 b/results/classifier/zero-shot/108/none/1968 new file mode 100644 index 000000000..359e688c1 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1968 @@ -0,0 +1,16 @@ +device: 0.562 +network: 0.497 +performance: 0.462 +PID: 0.446 +boot: 0.321 +vnc: 0.317 +semantic: 0.309 +KVM: 0.284 +socket: 0.270 +graphic: 0.193 +debug: 0.162 +other: 0.070 +permissions: 0.056 +files: 0.030 + +scripts (checkpatch): make braces {} necessary for 'for' loops diff --git a/results/classifier/zero-shot/108/none/197 b/results/classifier/zero-shot/108/none/197 new file mode 100644 index 000000000..80c706c0a --- /dev/null +++ b/results/classifier/zero-shot/108/none/197 @@ -0,0 +1,16 @@ +device: 0.583 +other: 0.575 +performance: 0.570 +debug: 0.535 +PID: 0.506 +vnc: 0.393 +KVM: 0.390 +network: 0.384 +socket: 0.313 +boot: 0.302 +permissions: 0.193 +graphic: 0.175 +files: 0.164 +semantic: 0.146 + +Unpredictable behaviour resulting in User process faults diff --git a/results/classifier/zero-shot/108/none/1974 b/results/classifier/zero-shot/108/none/1974 new file mode 100644 index 000000000..1e55908ce --- /dev/null +++ b/results/classifier/zero-shot/108/none/1974 @@ -0,0 +1,16 @@ +device: 0.556 +other: 0.398 +vnc: 0.386 +semantic: 0.370 +graphic: 0.349 +network: 0.332 +PID: 0.284 +performance: 0.261 +permissions: 0.240 +socket: 0.186 +boot: 0.154 +debug: 0.117 +KVM: 0.072 +files: 0.046 + +Default console changes break Xen command-line diff --git a/results/classifier/zero-shot/108/none/1983 b/results/classifier/zero-shot/108/none/1983 new file mode 100644 index 000000000..14b8835d4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1983 @@ -0,0 +1,45 @@ +graphic: 0.575 +device: 0.338 +semantic: 0.289 +debug: 0.153 +boot: 0.142 +network: 0.130 +PID: 0.124 +vnc: 0.120 +performance: 0.108 +other: 0.097 +socket: 0.097 +permissions: 0.092 +KVM: 0.043 +files: 0.042 + +Guest boot displays "virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1" and then happens Call Trace +Description of problem: +Guest boot displays "FATAL: Module scsi_wait_scan not found", and then happens Call Trace. + +``` +Call Trace: + dump_stack+0x4f/0x66 + panic+0xa2/0x258 + do_exit+0x858/0xab0 + do_group_exit+0x2f/0x90 + ? do_page_fault+0x18c/0x4c0 + sys_exit_group+0x11/0x20 + do_fast_syscall_32+0x8b/0x1c2 + entry_SYSENTER_32+0xa5/0xf8 +EIP: 0xb7fcec71 +Code: 89 01 31 c0 89 51 04 89 71 08 89 79 0c eb 03 83 c8 ff 83 c4 28 5b 5e 5f 5d c3 8b 1c 24 c3 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76 +EAX: ffffffda EBX: 00000001 ECX: 034c4745 EDX: 00000000 +ESI: 00000000 EDI: 00000000 EBP: bff7db18 ESP: bff7da3c +DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246 +Kernel Offset: 0x16c00000 from 0xc0400000 (relocation range: 0xc0000000-0xf75fdfff) +``` +Steps to reproduce: +1.Create guest by using the command + ``` + ./qemu-system-x86_64 -accel kvm -m 4096 -smp 4 -cpu host -drive file=test-img.qcow2,format=qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -monitor pty -daemonize -vnc :32137 -device virtio-net-pci,netdev=nic0,mac=00:c2:58:38:8e:f0 -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper,vhost=on + ``` +Additional information: +Suspected to be a QEMU regression issue, the first bad commit id: 14f5a7bae4cb5ca45a03e16b5bb0c5d766fd51b7. + +Latest successful version commit id: cea3ea670fe265421131aad90c36fbb87bc4d206 diff --git a/results/classifier/zero-shot/108/none/199 b/results/classifier/zero-shot/108/none/199 new file mode 100644 index 000000000..44b959348 --- /dev/null +++ b/results/classifier/zero-shot/108/none/199 @@ -0,0 +1,16 @@ +network: 0.574 +device: 0.523 +performance: 0.509 +permissions: 0.420 +socket: 0.419 +boot: 0.399 +semantic: 0.326 +graphic: 0.180 +PID: 0.176 +vnc: 0.172 +debug: 0.151 +other: 0.075 +files: 0.054 +KVM: 0.019 + +Convert QAPI to static types diff --git a/results/classifier/zero-shot/108/none/1994 b/results/classifier/zero-shot/108/none/1994 new file mode 100644 index 000000000..25e01d259 --- /dev/null +++ b/results/classifier/zero-shot/108/none/1994 @@ -0,0 +1,16 @@ +graphic: 0.368 +device: 0.263 +debug: 0.260 +boot: 0.162 +PID: 0.162 +semantic: 0.160 +performance: 0.091 +other: 0.067 +vnc: 0.062 +files: 0.022 +permissions: 0.007 +network: 0.007 +socket: 0.004 +KVM: 0.000 + +MacOS window sizing bug diff --git a/results/classifier/zero-shot/108/none/200 b/results/classifier/zero-shot/108/none/200 new file mode 100644 index 000000000..031e440c2 --- /dev/null +++ b/results/classifier/zero-shot/108/none/200 @@ -0,0 +1,16 @@ +device: 0.552 +performance: 0.491 +network: 0.463 +PID: 0.425 +semantic: 0.340 +boot: 0.308 +debug: 0.287 +socket: 0.280 +graphic: 0.265 +vnc: 0.248 +files: 0.214 +permissions: 0.200 +other: 0.144 +KVM: 0.053 + +Add Python linters (mypy, pylint, isort, flake8) to Gitlab CI diff --git a/results/classifier/zero-shot/108/none/2010 b/results/classifier/zero-shot/108/none/2010 new file mode 100644 index 000000000..7522e5a02 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2010 @@ -0,0 +1,95 @@ +permissions: 0.564 +graphic: 0.502 +semantic: 0.460 +network: 0.355 +debug: 0.340 +other: 0.340 +device: 0.313 +files: 0.304 +performance: 0.292 +PID: 0.281 +socket: 0.270 +vnc: 0.251 +boot: 0.245 +KVM: 0.207 + +The avocado test replay_kernel.py:ReplayKernelNormal.test_x86_64_pc is unreliable +Description of problem: +The replay test case is unreliable and often hangs at the second stage +Additional information: +The record stage complete fine: + +``` +2023-11-30 17:25:27,944 protocol L0481 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'. +2023-11-30 17:25:27,944 machine L0925 DEBUG| Opening console file +2023-11-30 17:25:27,944 machine L0903 DEBUG| Opening console socket +2023-11-30 17:25:42,652 __init__ L0153 DEBUG| [ 0.000000] Linux version 4.18.16-300.fc29.x86_64 (mockbuild@bkernel04.phx2.fedoraproject.org) (gcc version 8.2.1 20 +180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:24:08 UTC 2018 +2023-11-30 17:25:42,652 __init__ L0153 DEBUG| [ 0.000000] Command line: printk.time=1 panic=-1 console=ttyS0 +2023-11-30 17:25:42,652 __init__ L0153 DEBUG| [ 0.000000] x86/fpu: x87 FPU will use FXSAVE +2023-11-30 17:25:42,652 __init__ L0153 DEBUG| [ 0.000000] BIOS-provided physical RAM map: +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000007fdffff] usable +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x0000000007fe0000-0x0000000007ffffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] NX (Execute Disable) protection: active +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] SMBIOS 3.0.0 present. +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/201 +4 +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] last_pfn = 0x7fe0 max_arch_pfn = 0x400000000 +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] found SMP MP-table at [mem 0x000f5480-0x000f548f] mapped at [(____ptrval____)] +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: Early table checksum verification disabled +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: RSDP 0x00000000000F52A0 000014 (v00 BOCHS ) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: RSDT 0x0000000007FE1C78 000034 (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: FACP 0x0000000007FE1B2C 000074 (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: DSDT 0x0000000007FE0040 001AEC (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: FACS 0x0000000007FE0000 000040 +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: APIC 0x0000000007FE1BA0 000078 (v03 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: HPET 0x0000000007FE1C18 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: WAET 0x0000000007FE1C50 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] No NUMA configuration found +... +``` + +After recording the initial step the replay hangs shortly after mapping the BIOS until the test timeout terminates it. + +``` +2023-11-30 17:25:59,414 __init__ L0153 DEBUG| [ 0.000000] Linux version 4.18.16-300.fc29.x86_64 (mockbuild@bkernel04.phx2.fedoraproject.org) (gcc version 8.2.1 20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:24:08 UTC 2018 +2023-11-30 17:25:59,415 __init__ L0153 DEBUG| [ 0.000000] Command line: printk.time=1 panic=-1 console=ttyS0 +2023-11-30 17:25:59,415 __init__ L0153 DEBUG| [ 0.000000] x86/fpu: x87 FPU will use FXSAVE +2023-11-30 17:25:59,415 __init__ L0153 DEBUG| [ 0.000000] BIOS-provided physical RAM map: +2023-11-30 17:25:59,416 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +2023-11-30 17:25:59,416 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +2023-11-30 17:25:59,420 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] re +2023-11-30 17:27:28,826 stacktrace L0039 ERROR| +2023-11-30 17:27:28,826 stacktrace L0041 ERROR| Reproduced traceback from: /home/alex/lsrc/qemu.git/builds/all/pyvenv/lib/python3.11/site-packages/avocado/core/test.py:770 +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| Traceback (most recent call last): +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/pyvenv/lib/python3.11/site-packages/avocado/core/decorators.py", line 90, in wrapper +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| return function(obj, *args, **kwargs) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/replay_kernel.py", line 101, in test_x86_64_pc +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| self.run_rr(kernel_path, kernel_command_line, console_pattern, shift=5) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/replay_kernel.py", line 78, in run_rr +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| t2 = self.run_vm(kernel_path, kernel_command_line, console_pattern, +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/replay_kernel.py", line 61, in run_vm +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| self.wait_for_console_pattern(console_pattern, vm) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/boot_linux_console.py", line 52, in wait_for_console_pattern +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| wait_for_console_pattern(self, success_message, +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/avocado_qemu/__init__.py", line 199, in wait_for_console_pattern +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| _console_interaction(test, success_message, failure_message, None, vm=vm) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/avocado_qemu/__init__.py", line 148, in _console_interaction +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| msg = console.readline().decode().strip() +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^ +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/usr/lib/python3.11/socket.py", line 706, in readinto +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| return self._sock.recv_into(b) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^ +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/pyvenv/lib/python3.11/site-packages/avocado/plugins/runner.py", line 77, in sigterm_handler +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| raise RuntimeError("Test interrupted by SIGTERM") +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| RuntimeError: Test interrupted by SIGTERM +2023-11-30 17:27:28,827 stacktrace L0046 ERROR| +``` diff --git a/results/classifier/zero-shot/108/none/202 b/results/classifier/zero-shot/108/none/202 new file mode 100644 index 000000000..a6a3ad6f4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/202 @@ -0,0 +1,16 @@ +device: 0.559 +performance: 0.396 +network: 0.363 +semantic: 0.266 +graphic: 0.209 +permissions: 0.175 +debug: 0.158 +boot: 0.150 +vnc: 0.072 +files: 0.068 +PID: 0.029 +socket: 0.017 +other: 0.016 +KVM: 0.008 + +Move scripts/qmp/qom-* tooling into qemu.qmp.* diff --git a/results/classifier/zero-shot/108/none/2071 b/results/classifier/zero-shot/108/none/2071 new file mode 100644 index 000000000..e7684040f --- /dev/null +++ b/results/classifier/zero-shot/108/none/2071 @@ -0,0 +1,127 @@ +KVM: 0.428 +other: 0.387 +network: 0.363 +debug: 0.357 +device: 0.356 +graphic: 0.355 +semantic: 0.347 +vnc: 0.342 +performance: 0.333 +boot: 0.331 +permissions: 0.329 +PID: 0.329 +files: 0.314 +socket: 0.308 + +Segfault when starting a guest with spice configured to listen on a unix socket +Description of problem: +Guest crash immediately when spice is configured to listen on a unix socket. +Steps to reproduce: +1. Configure spice to listen on a unix socket +2. Start the guest +Additional information: +Here's the log when I start the guest: + +``` +[root@localhost ~]# virsh start fedora-waydroid +error: Failed to start domain 'fedora-waydroid' +error: internal error: qemu unexpectedly closed the monitor +``` +Here's the relevant output in journald: + +`SECCOMP auid=4294967295 uid=107 gid=107 ses=4294967295 pid=17930 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=0x7f7b95459397 code=0x80000000` + +<details><summary>Full journald</summary> + +``` +Jan 04 11:59:03 localhost polkitd[1436]: Registered Authentication Agent for unix-process:17895:5747660 (system bus name :1.160 [/usr/bin/pkttyagent --process 17895 --notify-fd 4 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) +Jan 04 11:59:03 localhost audit[1595]: VIRT_MACHINE_ID pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 vm-ctx=+107:+107 img-ctx=+107:+107 model=dac exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost virtlogd[1659]: Client hit max requests limit 1. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter +Jan 04 11:59:03 localhost virtlogd[1659]: Client hit max requests limit 1. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter +Jan 04 11:59:03 localhost polkitd[1436]: Unregistered Authentication Agent for unix-process:17895:5747660 (system bus name :1.160, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) +Jan 04 11:59:03 localhost audit: ANOM_PROMISCUOUS dev=vnet12 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=open vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 net=52:54:00:72:c3:92 path="/dev/net/tun" rdev=0A:C8 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=open vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 net=52:54:00:72:c3:92 path="/dev/vhost-net" rdev=0A:EE exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2422] manager: (vnet12): new Tun device (/org/freedesktop/NetworkManager/Devices/19) +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered blocking state +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered disabled state +Jan 04 11:59:03 localhost kernel: vnet12: entered allmulticast mode +Jan 04 11:59:03 localhost kernel: vnet12: entered promiscuous mode +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered blocking state +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered forwarding state +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2468] device (vnet12): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2470] device (vnet12): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2473] device (vnet12): Activation: starting connection 'vnet12' (abcdefgh-ijkl-mnop-qrst-uvwx12345679) +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2478] device (vnet12): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2479] device (vnet12): state change: prepare -> config (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2480] device (vnet12): state change: config -> ip-config (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2480] device (br-dmz): bridge port vnet12 was attached +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2480] device (vnet12): Activation: connection 'vnet12' enslaved, continuing activation +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2481] device (vnet12): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost systemd-machined[1368]: New machine qemu-10-fedora-waydroid. +Jan 04 11:59:03 localhost systemd[1]: Started machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope - Virtual Machine qemu-10-fedora-waydroid. +Jan 04 11:59:03 localhost systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service... +Jan 04 11:59:03 localhost audit: BPF prog-id=112 op=LOAD +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=deny vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=all exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/null" rdev=01:03 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/full" rdev=01:07 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/zero" rdev=01:05 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/random" rdev=01:08 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/urandom" rdev=01:09 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/ptmx" rdev=05:02 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/kvm" rdev=0A:E8 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=major category=pty maj=88 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/dri/by-path/pci-0000:00:02.0-render" rdev=E2:80 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/urandom" rdev=01:09 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service. +Jan 04 11:59:03 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2796] device (vnet12): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2797] device (vnet12): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2799] device (vnet12): Activation: successful, device activated. +Jan 04 11:59:03 localhost systemd[1]: iscsi.service: Unit cannot be reloaded because it is inactive. +Jan 04 11:59:03 localhost audit[17930]: SECCOMP auid=4294967295 uid=107 gid=107 ses=4294967295 pid=17930 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=0x7f7b95459397 code=0x80000000 +Jan 04 11:59:03 localhost audit[17930]: ANOM_ABEND auid=4294967295 uid=107 gid=107 ses=4294967295 pid=17930 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 res=1 +Jan 04 11:59:03 localhost audit: BPF prog-id=113 op=LOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=114 op=LOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=115 op=LOAD +Jan 04 11:59:03 localhost systemd[1]: Started systemd-coredump@3-17978-0.service - Process Core Dump (PID 17978/UID 0). +Jan 04 11:59:03 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@3-17978-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost systemd-coredump[17980]: Resource limits disable core dumping for process 17930 (qemu-system-x86). +Jan 04 11:59:03 localhost systemd-coredump[17980]: [🡕] Process 17930 (qemu-system-x86) of user 107 terminated abnormally without generating a coredump. +Jan 04 11:59:03 localhost systemd[1]: systemd-coredump@3-17978-0.service: Deactivated successfully. +Jan 04 11:59:03 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@3-17978-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit: ANOM_PROMISCUOUS dev=vnet12 prom=0 old_prom=256 auid=4294967295 uid=107 gid=107 ses=4294967295 +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered disabled state +Jan 04 11:59:03 localhost kernel: vnet12 (unregistering): left allmulticast mode +Jan 04 11:59:03 localhost kernel: vnet12 (unregistering): left promiscuous mode +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered disabled state +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.3895] device (vnet12): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.3897] device (vnet12): released from master device br-dmz +Jan 04 11:59:03 localhost virtqemud[1595]: Unable to read from monitor: Connection reset by peer +Jan 04 11:59:03 localhost virtqemud[1595]: internal error: qemu unexpectedly closed the monitor +Jan 04 11:59:03 localhost virtqemud[1595]: internal error: process exited while connecting to monitor +Jan 04 11:59:03 localhost virtlogd[1659]: Client hit max requests limit 1. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter +Jan 04 11:59:03 localhost virtqemud[1595]: Failed to acquire pid file '/run/libvirt/qemu/swtpm/10-fedora-waydroid-swtpm.pid': Resource temporarily unavailable +Jan 04 11:59:03 localhost systemd[1]: machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope: Deactivated successfully. +Jan 04 11:59:03 localhost systemd-machined[1368]: Machine qemu-10-fedora-waydroid terminated. +Jan 04 11:59:03 localhost audit: BPF prog-id=115 op=UNLOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=114 op=UNLOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=113 op=UNLOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=112 op=UNLOAD +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=disk reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-disk="?" new-disk="/var/lib/libvirt/images/fedora-waydroid.img" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-net="?" new-net="52:54:00:72:c3:92" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 bus=usb device=555342207265646972646576 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 bus=usb device=555342207265646972646576 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=rng reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-rng="?" new-rng="/dev/urandom" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=tpm-emulator reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 device="?" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=mem reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-mem=0 new-mem=4194304 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=vcpu reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-vcpu=0 new-vcpu=4 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_CONTROL pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm op=start reason=booted vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 vm-pid=0 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=failed' +``` + +<details> + +For the record I filed a bug earlier in libvirt (https://gitlab.com/libvirt/libvirt/-/issues/573) but I now think it's qemu related. + + +/label ~"kind::Bug" diff --git a/results/classifier/zero-shot/108/none/209 b/results/classifier/zero-shot/108/none/209 new file mode 100644 index 000000000..109c63e9c --- /dev/null +++ b/results/classifier/zero-shot/108/none/209 @@ -0,0 +1,16 @@ +graphic: 0.385 +device: 0.304 +performance: 0.218 +semantic: 0.169 +permissions: 0.089 +debug: 0.086 +vnc: 0.073 +other: 0.044 +network: 0.040 +files: 0.030 +PID: 0.023 +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/zero-shot/108/none/2098 b/results/classifier/zero-shot/108/none/2098 new file mode 100644 index 000000000..770021ecd --- /dev/null +++ b/results/classifier/zero-shot/108/none/2098 @@ -0,0 +1,16 @@ +device: 0.589 +network: 0.538 +semantic: 0.459 +performance: 0.417 +other: 0.328 +graphic: 0.298 +socket: 0.211 +debug: 0.187 +boot: 0.185 +permissions: 0.091 +files: 0.070 +PID: 0.065 +KVM: 0.039 +vnc: 0.011 + +AArch32 Arm CPUs no longer support the 'vfp' property diff --git a/results/classifier/zero-shot/108/none/2102 b/results/classifier/zero-shot/108/none/2102 new file mode 100644 index 000000000..28c8333a8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2102 @@ -0,0 +1,55 @@ +graphic: 0.179 +device: 0.132 +semantic: 0.125 +network: 0.085 +socket: 0.052 +vnc: 0.048 +PID: 0.043 +performance: 0.029 +permissions: 0.027 +files: 0.024 +debug: 0.024 +KVM: 0.010 +boot: 0.008 +other: 0.008 + +"qemu-img resize -f qcow2" produces broken disk images +Description of problem: +The documentation of `qemu-img` at +<https://www.qemu.org/docs/master/tools/qemu-img.html> +makes it sound like `qemu-img resize` supports various image formats +(raw, qcow2, etc.) in the same way. + +But it doesn't. While `qemu-img resize -f raw` works as expected, +`qemu-img resize -f qcow2` produces broken disk images. +Steps to reproduce: +``` +$ wget http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz +$ gunzip arm64.img +``` + +First resize, then convert: +``` +$ cp arm64.img arm64-rc.img +$ qemu-img resize -f raw arm64-rc.img 10G +$ qemu-img convert -f raw -O qcow2 arm64-rc.img arm64-rc.qcow2 +$ rm -f arm64-rc.img +``` + +First convert, then resize: +``` +$ qemu-img convert -f raw -O qcow2 arm64.img arm64-cr.qcow2 +$ qemu-img resize -f qcow2 arm64-cr.qcow2 10G +``` + +Attach to a VM in VirtualBox (as an additional SATA disk) and start that VM. + +arm64-rc.qcow2 => +`# fdisk /dev/sdb` => it has two partitions. + +arm64-cr.qcow2 => +`# fdisk /dev/sdb` => it has no partitions! +And the VM cannot be cleanly shut down. I had to manually kill the VirtualBoxVM +process. +Additional information: + diff --git a/results/classifier/zero-shot/108/none/2103 b/results/classifier/zero-shot/108/none/2103 new file mode 100644 index 000000000..344a267ca --- /dev/null +++ b/results/classifier/zero-shot/108/none/2103 @@ -0,0 +1,16 @@ +semantic: 0.517 +device: 0.489 +network: 0.233 +graphic: 0.220 +KVM: 0.175 +performance: 0.150 +PID: 0.132 +vnc: 0.131 +socket: 0.122 +other: 0.119 +boot: 0.110 +permissions: 0.100 +files: 0.064 +debug: 0.056 + +docs/system/keys.rst.inc still refers to removed options -alt-grab and -ctrl-grab diff --git a/results/classifier/zero-shot/108/none/2120 b/results/classifier/zero-shot/108/none/2120 new file mode 100644 index 000000000..7e3c74499 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2120 @@ -0,0 +1,16 @@ +network: 0.532 +semantic: 0.528 +device: 0.466 +PID: 0.201 +debug: 0.183 +files: 0.181 +performance: 0.161 +vnc: 0.104 +socket: 0.092 +permissions: 0.092 +boot: 0.082 +other: 0.070 +graphic: 0.043 +KVM: 0.014 + +arm64: Typo in isar_feature_aa64_tidcp1 diff --git a/results/classifier/zero-shot/108/none/2121 b/results/classifier/zero-shot/108/none/2121 new file mode 100644 index 000000000..60c70dfd5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2121 @@ -0,0 +1,16 @@ +performance: 0.530 +device: 0.474 +semantic: 0.359 +graphic: 0.323 +vnc: 0.317 +socket: 0.239 +network: 0.150 +PID: 0.130 +files: 0.113 +boot: 0.083 +permissions: 0.081 +debug: 0.068 +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/zero-shot/108/none/2129 b/results/classifier/zero-shot/108/none/2129 new file mode 100644 index 000000000..22ac5c263 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2129 @@ -0,0 +1,16 @@ +device: 0.399 +other: 0.356 +files: 0.276 +PID: 0.250 +graphic: 0.230 +vnc: 0.228 +performance: 0.225 +boot: 0.181 +KVM: 0.174 +socket: 0.087 +semantic: 0.072 +network: 0.063 +debug: 0.045 +permissions: 0.024 + +migration-test sometimes fails diff --git a/results/classifier/zero-shot/108/none/2130 b/results/classifier/zero-shot/108/none/2130 new file mode 100644 index 000000000..ea8ffa49e --- /dev/null +++ b/results/classifier/zero-shot/108/none/2130 @@ -0,0 +1,16 @@ +performance: 0.432 +other: 0.411 +semantic: 0.396 +graphic: 0.234 +device: 0.188 +debug: 0.168 +KVM: 0.144 +vnc: 0.118 +permissions: 0.093 +PID: 0.091 +network: 0.074 +boot: 0.064 +files: 0.054 +socket: 0.052 + +latest code missing "singlestep" diff --git a/results/classifier/zero-shot/108/none/214 b/results/classifier/zero-shot/108/none/214 new file mode 100644 index 000000000..deca8de6b --- /dev/null +++ b/results/classifier/zero-shot/108/none/214 @@ -0,0 +1,16 @@ +graphic: 0.535 +device: 0.531 +network: 0.501 +semantic: 0.279 +boot: 0.233 +vnc: 0.215 +permissions: 0.193 +performance: 0.190 +files: 0.129 +socket: 0.094 +other: 0.077 +debug: 0.058 +PID: 0.056 +KVM: 0.003 + +QEMU manpages provoke man(1) "can't break line" warnings diff --git a/results/classifier/zero-shot/108/none/2144 b/results/classifier/zero-shot/108/none/2144 new file mode 100644 index 000000000..337aa69d0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2144 @@ -0,0 +1,37 @@ +graphic: 0.120 +device: 0.103 +debug: 0.056 +semantic: 0.038 +PID: 0.014 +vnc: 0.010 +permissions: 0.010 +socket: 0.010 +files: 0.007 +other: 0.007 +boot: 0.006 +network: 0.004 +performance: 0.003 +KVM: 0.001 + +macOS build fails when using --enable-debug +Description of problem: +the build fails because a symbol can't be found: + +``` +ld: Undefined symbols: + _lasi_82596_init, referenced from: + _machine_HP_common_init_tail in hw_hppa_machine.c.o +``` +Steps to reproduce: +1. on macOS 14.3 in build folder +2. ../configure --enable-debug +3. make -j12 +Additional information: +the default build with + +``` +../configure +make -j12 +``` + +succeeds normally. diff --git a/results/classifier/zero-shot/108/none/2165 b/results/classifier/zero-shot/108/none/2165 new file mode 100644 index 000000000..01523921e --- /dev/null +++ b/results/classifier/zero-shot/108/none/2165 @@ -0,0 +1,83 @@ +KVM: 0.527 +other: 0.483 +vnc: 0.468 +graphic: 0.458 +boot: 0.448 +permissions: 0.442 +device: 0.439 +performance: 0.427 +debug: 0.413 +semantic: 0.408 +network: 0.404 +files: 0.393 +socket: 0.388 +PID: 0.387 + +m68k: 68000 strict alignment requirements not emulated correctly +Description of problem: +Unaligned accesses should cause an address error on the 68000 but apparently currently don't. +Steps to reproduce: +1. Create a 68000 based QEMU machine to port u-boot/linux +2. Get u-boot/linux working perfectly on your QEMU machine +3. Copy kernel over to your real 68000 hardware +4. Notice that the kernel doesn't work +5. Spend a day adding inline assembly all over the kernel to work out where the real hardware is locking up +6. Find that the issue is probably memmove() being called with an unaligned src pointer: + +C level.. + +``` +Breakpoint 1, memmove (n=215, src=0x2059df <printk_shared_pbufs+215>, dest=0x2059ee <printk_shared_pbufs+230>) at ../arch/m68k/lib/memmove.c:152 +152 *--sdest = *--ssrc; +(gdb) bt +#0 memmove (n=215, src=0x2059df <printk_shared_pbufs+215>, dest=0x2059ee <printk_shared_pbufs+230>) at ../arch/m68k/lib/memmove.c:152 +#1 memmove (dest=<optimized out>, src=<optimized out>, n=<optimized out>) at ../arch/m68k/lib/memmove.c:10 +#2 0x000265b6 in record_print_text (r=<optimized out>, syslog=<optimized out>, time=<optimized out>) at ../kernel/printk/printk.c:1472 +#3 0x00027be6 in printk_get_next_message (pmsg=<optimized out>, seq=<optimized out>, is_extended=<optimized out>, may_suppress=<optimized out>) at ../kernel/printk/printk.c:2952 +#4 0x00027e5a in console_emit_next_record (cookie=0, handover=0x1d9e37, con=0x1edf14 <early_con>) at ../kernel/printk/printk.c:3019 +#5 console_flush_all (do_cond_resched=false, next_seq=0x1d9e38, handover=0x1d9e37) at ../kernel/printk/printk.c:3118 +#6 0x00027fc8 in console_unlock () at ../kernel/printk/printk.c:3187 +#7 0x00028a04 in vprintk_emit (facility=0, level=<optimized out>, dev_info=0x0, fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk.c:2359 +#8 0x00028a26 in vprintk_default (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk.c:2374 +#9 0x00028c22 in vprintk (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk_safe.c:45 +#10 0x0019d016 in _printk (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n") at ../kernel/printk/printk.c:2384 +#11 0x0002857e in register_console (newcon=<optimized out>) at ../kernel/printk/printk.c:3693 +#12 0x001fbf1e in register_earlycon (match=<optimized out>, buf=0x0) at ../drivers/tty/serial/earlycon.c:161 +#13 setup_earlycon (buf=<optimized out>) at ../drivers/tty/serial/earlycon.c:212 +#14 0x001fbf72 in param_setup_earlycon (buf=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900") at ../drivers/tty/serial/earlycon.c:244 +#15 0x001f1102 in do_early_param (param=0x2009e0 <tmp_cmdline> "earlycon", val=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900", unused=0x1b96c6 "early options", arg=0x0) + at ../init/main.c:744 +#16 0x00017eac in parse_one (handle_unknown=<optimized out>, arg=<optimized out>, max_level=<optimized out>, min_level=<optimized out>, num_params=<optimized out>, params=<optimized out>, + doing=0x1b96c6 "early options", val=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900", param=0x2009e0 <tmp_cmdline> "earlycon") at ../kernel/params.c:154 +#17 parse_args (doing=<optimized out>, args=0x2009fe <tmp_cmdline+30> "console=ttyDB0 root=/dev/mmcblk0p2 rootfstype=squashfs rootwait", params=<optimized out>, num=<optimized out>, + min_level=<optimized out>, max_level=<optimized out>, arg=<optimized out>, unknown=<optimized out>) at ../kernel/params.c:189 +#18 0x001f13ea in parse_early_options (cmdline=0x2009e0 <tmp_cmdline> "earlycon") at ../init/main.c:754 +#19 0x001f1420 in parse_early_param () at ../init/main.c:769 +#20 0x001f1570 in start_kernel () at ../init/main.c:908 +#21 0x000004b8 in _clear_bss () at ../arch/m68k/dt/head.S:95 +#22 0x00000000 in ?? () +``` + +Asm level: + +``` +152 *--sdest = *--ssrc; + 0x0019bed8 <+324>: movel %a1,%d2 + 0x0019beda <+326>: subql #2,%d2 + 0x0019bedc <+328>: movel %a2,%d1 + 0x0019bede <+330>: subql #2,%d1 +=> 0x0019bee0 <+332>: movew %a1@(-2),%a2@(-2) +``` + +This is a word store so needs to be aligned but a1 isn't aligned so we should get an address error: + +``` +(gdb) print/x $a1 +$3 = 0x2059df +(gdb) print/x $a2 +$4 = 0x2059ee +``` + + +7. Check QEMU source code to work out why it doesn't crash the cpu at the same place. +8. Notice it doesn't seem to check the alignment. diff --git a/results/classifier/zero-shot/108/none/2176 b/results/classifier/zero-shot/108/none/2176 new file mode 100644 index 000000000..1c08faccb --- /dev/null +++ b/results/classifier/zero-shot/108/none/2176 @@ -0,0 +1,16 @@ +device: 0.392 +semantic: 0.284 +performance: 0.244 +boot: 0.216 +graphic: 0.152 +other: 0.146 +socket: 0.117 +PID: 0.109 +vnc: 0.087 +KVM: 0.056 +network: 0.042 +files: 0.034 +permissions: 0.019 +debug: 0.010 + +Events delivered during Capabilities Negotiation mode diff --git a/results/classifier/zero-shot/108/none/2191 b/results/classifier/zero-shot/108/none/2191 new file mode 100644 index 000000000..970243f1d --- /dev/null +++ b/results/classifier/zero-shot/108/none/2191 @@ -0,0 +1,16 @@ +socket: 0.561 +network: 0.559 +device: 0.556 +permissions: 0.536 +boot: 0.445 +PID: 0.343 +KVM: 0.321 +vnc: 0.292 +files: 0.235 +performance: 0.218 +other: 0.162 +semantic: 0.127 +graphic: 0.107 +debug: 0.065 + +Support exposing exports based on authentication diff --git a/results/classifier/zero-shot/108/none/2204 b/results/classifier/zero-shot/108/none/2204 new file mode 100644 index 000000000..1218b68af --- /dev/null +++ b/results/classifier/zero-shot/108/none/2204 @@ -0,0 +1,88 @@ +files: 0.532 +device: 0.520 +boot: 0.510 +permissions: 0.495 +PID: 0.494 +performance: 0.479 +graphic: 0.475 +KVM: 0.475 +other: 0.459 +network: 0.423 +semantic: 0.401 +vnc: 0.341 +debug: 0.305 +socket: 0.222 + +Hyper-V on Windows Server 2022 cannot load images converted from OVA to VHDX by qemu-img: Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device +Description of problem: +We have reference OVA image: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova and we want to convert it to VMDX format. +Steps to reproduce: +I downloaded reference OVA and converted it to VMDX with three possible options. + +With subformat dynamic: +``` +qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=dynamic fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx +``` + +And without it: +``` +qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx +``` + +And with explicitly setting fixed: +``` +qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=fixed fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx +``` + +In all cases I tried loading images using VM of Generation 1 and Generation 2: +``` +The application encountered an error while attempting to change the state of +'New Virtual Machine'. + +'New Virtual Machine' failed to start. + +Microsoft Emulated IDE Controller (Instance ID 83F8638B-8DCA-4152-9EDA-2CA8B33039B4): Failed to Power on with Error 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.. + +Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.hdx''. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.. + +Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.vhdx'. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.'. +``` + +I noticed some similarities with https://gitlab.com/qemu-project/qemu/-/issues/136 and applied workaround to fix it: +``` +fsutil sparse setflag fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx 0 +``` + +It started complaining that file is being used by another app. I waited long enough and then rebooted server. + +After that error changed to: +``` +Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device_ +``` + +As image: + + + +For Generation 2 error is slightly different: +``` +Virtual Machine Boot Summary +1. SCSI Disk +(0,0) +The boot loader did not load an operating system. +2. Network Adapter (00155D01770C) +A boot image was not found. +``` + +As image:  + +I tried doing conversion from VirtualBox with same OVA and it worked just fine: +``` +VBoxManage clonehd fastnetmon-ubuntu-22.04-amd64-disk1.vmdk fastnetmon.vhd --format vhd +``` + +I believe something is wrong with boot records for VMDX images. + +Example of converted VHDX with dynamic flag can be found here: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.356.0.vhdx + +By Pavel Odintsov at FastNetMon.com diff --git a/results/classifier/zero-shot/108/none/2227 b/results/classifier/zero-shot/108/none/2227 new file mode 100644 index 000000000..c11d0a7b4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2227 @@ -0,0 +1,51 @@ +KVM: 0.443 +other: 0.419 +graphic: 0.365 +vnc: 0.363 +device: 0.347 +debug: 0.343 +permissions: 0.329 +performance: 0.316 +PID: 0.303 +boot: 0.291 +semantic: 0.290 +files: 0.268 +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/zero-shot/108/none/2239 b/results/classifier/zero-shot/108/none/2239 new file mode 100644 index 000000000..9456a924f --- /dev/null +++ b/results/classifier/zero-shot/108/none/2239 @@ -0,0 +1,16 @@ +permissions: 0.329 +device: 0.221 +graphic: 0.199 +semantic: 0.097 +boot: 0.041 +PID: 0.037 +vnc: 0.034 +performance: 0.031 +debug: 0.019 +files: 0.015 +network: 0.011 +KVM: 0.010 +socket: 0.008 +other: 0.005 + +Legacy system requirments: iptables diff --git a/results/classifier/zero-shot/108/none/2249 b/results/classifier/zero-shot/108/none/2249 new file mode 100644 index 000000000..37b8c05bf --- /dev/null +++ b/results/classifier/zero-shot/108/none/2249 @@ -0,0 +1,48 @@ +device: 0.500 +PID: 0.355 +graphic: 0.337 +socket: 0.316 +other: 0.276 +performance: 0.240 +files: 0.228 +vnc: 0.223 +permissions: 0.210 +boot: 0.207 +semantic: 0.194 +network: 0.185 +debug: 0.185 +KVM: 0.033 + +[qemu-system-m68k] [q800] Ishar 1 makes Qemu crash +Description of problem: +qemu-system-m68k crashes when running the classic RPG game "Ishar", this is what can be seen on the TTY console on the host system: + +``` +qemu: fatal: DOUBLE MMU FAULT + +D0 = 000000af A0 = 000b91d2 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000074 A1 = 50f02000 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00067274 F2 = 7fff ffffffffffffffff ( nan) +D3 = f7f6f600 A3 = 40809be0 F3 = 7fff ffffffffffffffff ( nan) +D4 = f8ff2a2a A4 = 00000000 F4 = 7fff ffffffffffffffff ( nan) +D5 = 54aa0027 A5 = 007ef2b8 F5 = 7fff ffffffffffffffff ( nan) +D6 = 0000000a A6 = 000001e3 F6 = 7fff ffffffffffffffff ( nan) +D7 = ffffffe6 A7 = 0000000a F7 = 7fff ffffffffffffffff ( nan) +PC = 00067288 SR = 2218 T:0 I:2 SI XN--- +FPSR = 00000000 ---- + FPCR = 0000 X RN + A7(MSP) = 00000000 A7(USP) = 00000000 ->A7(ISP) = 0000000a +VBR = 0x00000000 +SFC = 0 DFC 5 +SSW 00000445 TCR 0000c000 URP 00000000 SRP 01ff6c00 +DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000 +MMUSR 00000000, fault at fffffffe +./mac: line 5: 806788 Aborted (core dumped) qemu-system-m68k -M q800 -m 32 -bios q800.rom -display sdl -audio driver=alsa -device scsi-hd,scsi-id=0,drive=hd0 -drive file=system71.img,media=disk,format=raw,if=none,id=hd0 -display sdl +``` +Steps to reproduce: +1. Download Ishar 1 Color version (available in https://www.grenier-du-mac.net/fiches/Jeux/ishar1.htm, on the lower part of the page). +2. Copy it to the emulated system and decompress the .sit archive with Stuffit Expander 5.5 +3. Run the game by clicking on it's icon and clicking on "Commandes->Jouer" or pressing Command+J +4. Watch it making qemu-system-m68k crash'n burn! +Additional information: +The same game works fine on current MAME Mac II/Ci emulation, etc. diff --git a/results/classifier/zero-shot/108/none/228 b/results/classifier/zero-shot/108/none/228 new file mode 100644 index 000000000..37bb9e6f5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/228 @@ -0,0 +1,16 @@ +device: 0.564 +performance: 0.284 +semantic: 0.249 +other: 0.241 +graphic: 0.162 +permissions: 0.128 +boot: 0.080 +network: 0.065 +vnc: 0.048 +PID: 0.032 +socket: 0.030 +files: 0.023 +debug: 0.021 +KVM: 0.018 + +TCG test targets missing from 'make check-help' diff --git a/results/classifier/zero-shot/108/none/229 b/results/classifier/zero-shot/108/none/229 new file mode 100644 index 000000000..3bf1a6c6f --- /dev/null +++ b/results/classifier/zero-shot/108/none/229 @@ -0,0 +1,16 @@ +graphic: 0.340 +device: 0.189 +semantic: 0.142 +other: 0.118 +boot: 0.074 +performance: 0.053 +vnc: 0.048 +PID: 0.044 +files: 0.036 +socket: 0.035 +KVM: 0.034 +network: 0.023 +permissions: 0.008 +debug: 0.008 + +build-tools-and-docs-debian job waste cycles building pointless things diff --git a/results/classifier/zero-shot/108/none/2298 b/results/classifier/zero-shot/108/none/2298 new file mode 100644 index 000000000..894b83b22 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2298 @@ -0,0 +1,27 @@ +graphic: 0.543 +semantic: 0.444 +device: 0.213 +vnc: 0.193 +socket: 0.168 +network: 0.139 +performance: 0.126 +boot: 0.087 +files: 0.085 +KVM: 0.052 +permissions: 0.046 +debug: 0.033 +other: 0.029 +PID: 0.027 + +Invariant result in opts-visitor.c +Description of problem: +Expressions: +1) val2 <= INT64_MAX +2) INT64_MIN <= val2 +in line [431](https://github.com/qemu/qemu/blob/62dbe54c24dbf77051bafe1039c31ddc8f37602d/qapi/opts-visitor.c#L431) are always true. + +Seems like this checks are redundant. + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Burke. diff --git a/results/classifier/zero-shot/108/none/2304 b/results/classifier/zero-shot/108/none/2304 new file mode 100644 index 000000000..1e3a9d407 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2304 @@ -0,0 +1,53 @@ +graphic: 0.541 +performance: 0.381 +device: 0.366 +semantic: 0.331 +network: 0.328 +other: 0.309 +socket: 0.305 +PID: 0.231 +permissions: 0.213 +vnc: 0.208 +debug: 0.182 +boot: 0.173 +files: 0.096 +KVM: 0.088 + +Disabling SVE via `-cpu max,sve=off` leaves SVE2 advertised by `getauxval` +Description of problem: +The documentation on https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html suggests that it should be possible to disable SVE support by passing `-cpu max,sve=off` on the command line, however this appears to only disable the SVE support advertised in the return value from `getauxval(AT_HWCAP)`. In particular it leaves SVE2 reported as enabled. This leaves the feature set advertised by `getauxval` in an inconsistent state since SVE is mandatory if SVE2 is available. + +This may also affect other feature dependencies for example FEAT_SVE_BITPerm also requiring SVE2 to be available, I've not checked exhaustively. + +For example, given the following code: + + #include <sys/auxv.h> + #include <stdio.h> + + int main() { + unsigned long hwcap = getauxval(AT_HWCAP); + unsigned long hwcap2 = getauxval(AT_HWCAP2); + + if (hwcap & HWCAP_SVE) { + printf("have sve!\n"); + } else { + printf("don't have sve!\n"); + } + if (hwcap2 & HWCAP2_SVE2) { + printf("have sve2!\n"); + } else { + printf("don't have sve2!\n"); + } + } + +We can observe the following: + + $ aarch64-linux-gnu-gcc test.c -static + $ ../qemu-aarch64 -cpu max ./a.out + have sve! + have sve2! + $ ../qemu-aarch64 -cpu max,sve=off ./a.out + don't have sve! + have sve2! + +I don't believe that there is a `-cpu ...,sve2=off` option, so I would expect that disabling SVE also prevents SVE2 from being advertised as available. diff --git a/results/classifier/zero-shot/108/none/2309 b/results/classifier/zero-shot/108/none/2309 new file mode 100644 index 000000000..d1e141ae8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2309 @@ -0,0 +1,46 @@ +device: 0.371 +semantic: 0.339 +graphic: 0.331 +debug: 0.310 +PID: 0.284 +performance: 0.200 +permissions: 0.148 +socket: 0.103 +boot: 0.095 +vnc: 0.094 +other: 0.078 +files: 0.066 +network: 0.044 +KVM: 0.008 + +qemu-aarch64 hangs running cargo test after libc6 upgrade to 2.36-9+deb12u6 +Description of problem: +qemu-aarch64 seems to hang with 100% cpu usage without any indication. +with -p 12345 for gdb debugging, gdb could not interrupt the remote with ctrl-c. +Steps to reproduce: +1. Ensure the test env has 2.36-9+deb12u6 +2. Install the latest rust toolchain. +3. mkdir test_test && cargo init +4. ensure src/main.rs has +``` +fn main() { + println!("Hello, world!"); +} + +#[test] +fn test() { + println!("hAAA!"); +} +``` +5. create .cargo/config.toml +``` +[target.aarch64-unknown-linux-gnu] +linker = "aarch64-linux-gnu-gcc" +runner = "qemu-aarch64 -L /usr/aarch64-linux-gnu" +rustflags = ["-C", "target-cpu=neoverse-n1"] +``` +6. cargo test --target aarch64-unknown-linux-gnu +Additional information: +The issue does not seem to occur with libc6:2.36-9+deb12u4 + +The same binary runs fine on a real arm64 target with the upgraded libc6 version 2.36-9+deb12u6. diff --git a/results/classifier/zero-shot/108/none/231 b/results/classifier/zero-shot/108/none/231 new file mode 100644 index 000000000..620b1fd06 --- /dev/null +++ b/results/classifier/zero-shot/108/none/231 @@ -0,0 +1,16 @@ +device: 0.586 +graphic: 0.539 +performance: 0.515 +debug: 0.055 +permissions: 0.052 +semantic: 0.045 +network: 0.043 +other: 0.027 +boot: 0.026 +PID: 0.020 +vnc: 0.013 +socket: 0.011 +files: 0.010 +KVM: 0.002 + +Many leaks from qemu_spice_create_update diff --git a/results/classifier/zero-shot/108/none/2328 b/results/classifier/zero-shot/108/none/2328 new file mode 100644 index 000000000..0003fef89 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2328 @@ -0,0 +1,16 @@ +performance: 0.569 +network: 0.500 +device: 0.499 +socket: 0.471 +files: 0.417 +boot: 0.362 +vnc: 0.312 +KVM: 0.306 +graphic: 0.249 +semantic: 0.219 +debug: 0.158 +PID: 0.150 +other: 0.127 +permissions: 0.093 + +sha1.c:161:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 0 diff --git a/results/classifier/zero-shot/108/none/2369 b/results/classifier/zero-shot/108/none/2369 new file mode 100644 index 000000000..523bd7f7a --- /dev/null +++ b/results/classifier/zero-shot/108/none/2369 @@ -0,0 +1,16 @@ +graphic: 0.560 +device: 0.430 +semantic: 0.427 +other: 0.426 +performance: 0.412 +boot: 0.217 +network: 0.181 +files: 0.118 +permissions: 0.101 +debug: 0.090 +vnc: 0.076 +PID: 0.066 +socket: 0.052 +KVM: 0.019 + +qemu-img measure is incorrect when using discard-no-unref diff --git a/results/classifier/zero-shot/108/none/237 b/results/classifier/zero-shot/108/none/237 new file mode 100644 index 000000000..18261ed7b --- /dev/null +++ b/results/classifier/zero-shot/108/none/237 @@ -0,0 +1,16 @@ +device: 0.503 +performance: 0.387 +permissions: 0.269 +boot: 0.249 +semantic: 0.234 +graphic: 0.204 +debug: 0.202 +other: 0.187 +network: 0.157 +socket: 0.116 +files: 0.052 +PID: 0.050 +vnc: 0.048 +KVM: 0.013 + +[Feature request] x86: dump MSR features in human form diff --git a/results/classifier/zero-shot/108/none/2389 b/results/classifier/zero-shot/108/none/2389 new file mode 100644 index 000000000..22e3d22c6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2389 @@ -0,0 +1,49 @@ +graphic: 0.528 +semantic: 0.447 +other: 0.361 +performance: 0.244 +device: 0.186 +debug: 0.121 +PID: 0.072 +network: 0.062 +vnc: 0.059 +files: 0.056 +socket: 0.033 +boot: 0.024 +permissions: 0.018 +KVM: 0.008 + +Mutex initialization assertion failure due to incompatibility with macOS setrlimit() syscall +Description of problem: +Running the command with with any set of arguments instantly crashes with the following error message: + +``` +Assertion failed: (mutex->initialized), function qemu_mutex_lock_impl, file ../util/qemu-thread-posix.c, line 92. +zsh: abort ./qemu-system-x86_64 +``` +Steps to reproduce: +As per instructions for building from scratch: + +1. `mkdir build && cd build` +2. `../configure --prefix=$PWD/.. --audio-drv-list=sdl --disable-cocoa --enable-sdl --enable-sdl-image` +3. `make && make install` +4. `cd ../bin` +5. `./qemu-system-x86_64` +Additional information: +The issue is coming from the `os_setup_limits()` function in `os-posix.c`. As it turns out, the `setrlimit()` syscall behaves subtly different on macOS than on Linux systems, and the macOS man pages explicitly forbade the code on line 273. + +Line 273 from `os-posix.c`: + +``` +nofile.rlim_cur = nofile.rlim_max; +``` + +macOS `setrlimit()` man page: + +``` +COMPATIBILITY + setrlimit() now returns with errno set to EINVAL in places that historically succeeded. It no longer accepts "rlim_cur = RLIM_INFINITY" for + RLIM_NOFILE. Use "rlim_cur = min(OPEN_MAX, rlim_max)". +``` + +The man page thankfully gives us the [patch](/uploads/e7c8c6e3b5620c3b1ee34e89661097f3/qemu.patch) diff --git a/results/classifier/zero-shot/108/none/2391 b/results/classifier/zero-shot/108/none/2391 new file mode 100644 index 000000000..836960133 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2391 @@ -0,0 +1,31 @@ +device: 0.567 +graphic: 0.517 +semantic: 0.376 +PID: 0.256 +other: 0.223 +permissions: 0.209 +network: 0.149 +vnc: 0.099 +debug: 0.097 +socket: 0.083 +performance: 0.060 +files: 0.057 +boot: 0.047 +KVM: 0.012 + +virglrenderer related -device help failure +Description of problem: +When QEMU is compiled against a recent `virglrenderer` version, running the above command fails like this: +``` +$ qemu-system-x86_64 -device virtio-vga-gl,help +qemu-system-x86_64: -device virtio-vga-gl,help: failed to open module: /usr/bin/../lib/qemu/hw-display-virtio-gpu-gl.so: undefined symbol: qemu_egl_display +``` +Steps to reproduce: +1. build QEMU against latest `virglrenderer` (1.0.1) +2. run the above command +Additional information: +The cause appears to be related to e8a2db94 cc @marcandre.lureau-rh + +Arch only recently updated to latest `virglrenderer` which has exposed the issue. + +Note that the device seems to function correctly in normal usage when combined with -display e.g. `-device virtio-vga-gl -display gtk,gl=on` diff --git a/results/classifier/zero-shot/108/none/2397 b/results/classifier/zero-shot/108/none/2397 new file mode 100644 index 000000000..6fe05e581 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2397 @@ -0,0 +1,16 @@ +device: 0.585 +performance: 0.583 +files: 0.448 +network: 0.373 +semantic: 0.314 +graphic: 0.254 +vnc: 0.229 +PID: 0.212 +boot: 0.194 +permissions: 0.135 +socket: 0.108 +other: 0.093 +debug: 0.080 +KVM: 0.067 + +Restrict qemu_file_set_error_obj() to migration/ diff --git a/results/classifier/zero-shot/108/none/2401 b/results/classifier/zero-shot/108/none/2401 new file mode 100644 index 000000000..d2b656902 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2401 @@ -0,0 +1,16 @@ +other: 0.596 +semantic: 0.460 +device: 0.368 +performance: 0.278 +network: 0.174 +KVM: 0.155 +graphic: 0.154 +files: 0.151 +debug: 0.120 +vnc: 0.092 +boot: 0.075 +permissions: 0.067 +PID: 0.046 +socket: 0.036 + +"-nic none" option has no equivalent in config file diff --git a/results/classifier/zero-shot/108/none/2426 b/results/classifier/zero-shot/108/none/2426 new file mode 100644 index 000000000..0c5b88c17 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2426 @@ -0,0 +1,16 @@ +device: 0.509 +performance: 0.410 +graphic: 0.212 +debug: 0.179 +boot: 0.140 +PID: 0.119 +semantic: 0.112 +KVM: 0.076 +vnc: 0.058 +other: 0.046 +socket: 0.036 +permissions: 0.012 +files: 0.004 +network: 0.003 + +How to determine which cpu microarchitecture is suitable for use on Windows 11? diff --git a/results/classifier/zero-shot/108/none/2446 b/results/classifier/zero-shot/108/none/2446 new file mode 100644 index 000000000..03ae2bd62 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2446 @@ -0,0 +1,75 @@ +graphic: 0.594 +other: 0.515 +device: 0.495 +PID: 0.487 +network: 0.481 +permissions: 0.476 +performance: 0.440 +debug: 0.439 +vnc: 0.436 +semantic: 0.436 +files: 0.415 +boot: 0.382 +socket: 0.340 +KVM: 0.332 + +linux-user: Qemu doesn't support `set_robust_list` used by glibc robust mutex implementation +Description of problem: +It seems that syscall set_robust_list is not implemented on Qemu for any Linux platform: [link]( https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L12811) +Steps to reproduce: +1. Use below toy program `set_robust_list.c` and compile it without optimizations like: +``` + gcc -Wall -W -Wextra -std=gnu17 -pedantic set_robust_list.c -o set_robust_list +``` + +``` +#include <stdio.h> +#include <stdlib.h> +#include <errno.h> +#include <sys/syscall.h> +#include <sys/types.h> +#include <unistd.h> +#include <linux/futex.h> +#include <syscall.h> + +int main(void) +{ +#ifdef __NR_set_robust_list + struct robust_list_head head; + size_t len = sizeof(struct robust_list_head); + + // This call to set_robust_list function should fail + int err = syscall(__NR_set_robust_list, &head, -1); + if (err < 0) + perror("1st set_robust_list error"); + else + puts("1st set_robust_list OK"); + + // This call to set_robust_list function should be sucessful + err = syscall(__NR_set_robust_list, &head, len); + if (err < 0) + perror("2nd set_robust_list error"); + else + puts("2nd set_robust_list OK"); +#else + puts("No set_robust_list support"); +#endif + exit(0); +} +``` + +2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: +``` +root@AMDC4705:/runtime/set_robust_list# ./set_robust_list +1st set_robust_list error: Invalid argument +2nd set_robust_list OK +root@AMDC4705:/runtime/set_robust_list# ./set_robust_list-riscv +1st set_robust_list error: Function not implemented +2nd set_robust_list error: Function not implemented +``` +Additional information: +Working `set_robust_list` on Linux is quite important in context of named robust mutexes. In NPTL `set_robust_list` is used internally at ld.so initialization time to perform following check: [link](https://github.com/bminor/glibc/blob/master/sysdeps/nptl/dl-tls_init_tp.c#L96) + +When syscall fails, later `pthread_mutex_init` (with `PTHREAD_MUTEX_ROBUST` + `PTHREAD_PROCESS_SHARED` attributes) end up with `ENOTSUP` error [link](https://github.com/bminor/glibc/blob/master/nptl/pthread_mutex_init.c#L99). + +In dotnet we use robust mutexes for process synchronization purpose. Although there are other available techniques like named semaphores or file locks, robust mutexes are better locking option in case of unexpected process death. diff --git a/results/classifier/zero-shot/108/none/2447 b/results/classifier/zero-shot/108/none/2447 new file mode 100644 index 000000000..c0003fda5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2447 @@ -0,0 +1,38 @@ +KVM: 0.506 +device: 0.445 +graphic: 0.410 +performance: 0.364 +semantic: 0.341 +PID: 0.296 +socket: 0.235 +permissions: 0.214 +vnc: 0.152 +boot: 0.135 +network: 0.121 +other: 0.118 +files: 0.100 +debug: 0.064 + +With -display sdl,gl=on and 3D acceleration, the position of mouse does not show correctly +Description of problem: +Real mouse position is nearly 100 px on the left of drawn cursor. The closer the cursor to the lower right corner of the VM window, the worse (divergence becomes way bigger than 100 px). + +Split off from https://gitlab.com/qemu-project/qemu/-/issues/761 + +VM window is not necessary to be resized to reproduce this bug. If your VM desktop comes 1920x1080 originally, the bug can be reproduced from the very start. + +Smaller resolutions show this bug too, but it not so noticeable. +Steps to reproduce: +1. Download and install official QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe +2. Go to https://www.kali.org/get-kali/#kali-virtual-machines and click big QEMU 64 icon, and wait till kali-linux-2024.2-qemu-amd64.7z has been downloaded +3. Extract kali-linux-2024.2-qemu-amd64.qcow2 from kali-linux-2024.2-qemu-amd64.7z +4. Run it: `qemu-system-x86_64.exe -accel tcg -device virtio-vga-gl -display sdl,gl=on -hda C:\kali-linux-2024.2-qemu-amd64.qcow2 -usb -device usb-tablet -m 4096 -machine q35 -smp 2 -cpu Westmere` +5. Enter `kali` as user and `kali` as password when prompted +6. When the desktop is shown up, click the leftmost, upmost blue "Applications" button. Then click Settings -\> Display +7. Pick 1920x1080 as resolution and click Apply, then Keep this configuration. +8. Click Firefox Browser icon on the top panel. +9. When the browser starts working, experience how hard to use its interface, though it's fast. Real mouse position is nearly 100 px on the left of drawn cursor. The closer the cursor to the lower right corner of the VM window, the worse (divergence becomes way bigger than 100 px). +Additional information: +Run `qemu-system-x86_64.exe -accel tcg -device virtio-vga -display sdl -hda C:\kali-linux-2024.2-qemu-amd64.qcow2 -usb -device usb-tablet -m 4096 -machine q35 -smp 2 -cpu Westmere` and experience correct behavior. + +Mouse in Gtk mode works ok. OpenGL not available for Windows in GTK mode. diff --git a/results/classifier/zero-shot/108/none/2449 b/results/classifier/zero-shot/108/none/2449 new file mode 100644 index 000000000..53d661354 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2449 @@ -0,0 +1,16 @@ +semantic: 0.515 +files: 0.466 +graphic: 0.147 +device: 0.100 +boot: 0.037 +vnc: 0.030 +other: 0.025 +permissions: 0.022 +socket: 0.015 +network: 0.014 +KVM: 0.006 +PID: 0.006 +performance: 0.004 +debug: 0.004 + +How to extract FIS (personal question) diff --git a/results/classifier/zero-shot/108/none/2451 b/results/classifier/zero-shot/108/none/2451 new file mode 100644 index 000000000..8a91f3c60 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2451 @@ -0,0 +1,16 @@ +permissions: 0.516 +semantic: 0.337 +debug: 0.331 +other: 0.280 +device: 0.222 +boot: 0.212 +performance: 0.192 +graphic: 0.164 +socket: 0.156 +files: 0.103 +PID: 0.061 +KVM: 0.021 +network: 0.018 +vnc: 0.002 + +Italian language (po) not updated diff --git a/results/classifier/zero-shot/108/none/2458 b/results/classifier/zero-shot/108/none/2458 new file mode 100644 index 000000000..e2fd13b1a --- /dev/null +++ b/results/classifier/zero-shot/108/none/2458 @@ -0,0 +1,16 @@ +device: 0.581 +files: 0.487 +vnc: 0.260 +permissions: 0.227 +semantic: 0.207 +debug: 0.197 +PID: 0.131 +socket: 0.115 +other: 0.075 +graphic: 0.070 +network: 0.051 +performance: 0.026 +boot: 0.009 +KVM: 0.004 + +Documentation build fails with Sphinx 8 diff --git a/results/classifier/zero-shot/108/none/2467 b/results/classifier/zero-shot/108/none/2467 new file mode 100644 index 000000000..4703377e2 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2467 @@ -0,0 +1,46 @@ +graphic: 0.264 +device: 0.255 +PID: 0.215 +socket: 0.143 +performance: 0.140 +boot: 0.138 +semantic: 0.132 +network: 0.128 +permissions: 0.120 +other: 0.111 +vnc: 0.102 +debug: 0.090 +files: 0.054 +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/zero-shot/108/none/2481 b/results/classifier/zero-shot/108/none/2481 new file mode 100644 index 000000000..bd832179b --- /dev/null +++ b/results/classifier/zero-shot/108/none/2481 @@ -0,0 +1,16 @@ +semantic: 0.455 +graphic: 0.446 +debug: 0.329 +KVM: 0.281 +device: 0.281 +vnc: 0.228 +performance: 0.205 +boot: 0.190 +other: 0.173 +socket: 0.049 +network: 0.044 +files: 0.043 +PID: 0.019 +permissions: 0.010 + +Possible dereference of NULL diff --git a/results/classifier/zero-shot/108/none/2501 b/results/classifier/zero-shot/108/none/2501 new file mode 100644 index 000000000..fbec941f2 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2501 @@ -0,0 +1,16 @@ +performance: 0.432 +device: 0.425 +semantic: 0.298 +graphic: 0.224 +permissions: 0.111 +network: 0.077 +PID: 0.044 +debug: 0.034 +other: 0.024 +boot: 0.023 +vnc: 0.020 +files: 0.016 +socket: 0.007 +KVM: 0.004 + +compile qemu as a shared library diff --git a/results/classifier/zero-shot/108/none/2527 b/results/classifier/zero-shot/108/none/2527 new file mode 100644 index 000000000..1d26d54d8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2527 @@ -0,0 +1,16 @@ +device: 0.543 +performance: 0.511 +other: 0.404 +network: 0.375 +semantic: 0.302 +graphic: 0.214 +permissions: 0.201 +boot: 0.198 +vnc: 0.175 +PID: 0.151 +files: 0.142 +debug: 0.133 +socket: 0.090 +KVM: 0.070 + +bFLT parser doesn't select MMU-less CPU diff --git a/results/classifier/zero-shot/108/none/2566 b/results/classifier/zero-shot/108/none/2566 new file mode 100644 index 000000000..896388b79 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2566 @@ -0,0 +1,134 @@ +KVM: 0.576 +network: 0.557 +performance: 0.552 +device: 0.472 +permissions: 0.462 +graphic: 0.456 +vnc: 0.452 +debug: 0.439 +PID: 0.421 +files: 0.397 +semantic: 0.397 +socket: 0.392 +other: 0.374 +boot: 0.361 + +Plugin deadlock with qemu_plugin_register_vcpu_mem_cb introduced prior to v8.1.0 +Description of problem: +Between v8.0.5 and v8.1.0 a bug was introduced where a TCG plugin calling `qemu_plugin_register_vcpu_mem_cb` can cause a deadlock. This bug is still present in the current head of master (a66f28df650166ae8b50c992eea45e7b247f4143). + +I was able to reproduce this reliably (>95% of the time) testing with the minimal plugin shown below. In more limited testing, I found the logic in the (in-tree) hotpages plugin will also trigger this deadlock. + +I tested with the Ubuntu Bionic qcow from [here](https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2), but don't think there's anything particularly special about this qcow. + + +A minimal plugin to trigger the deadlock is as follows. To build the plugin, you'll need to add a `NAMES += customtest` line into `contrib/plugins/Makefile. + +contrib/plugins/customtest.c: +``` +#include <qemu-plugin.h> + +QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + +static void vcpu_mem(unsigned int cpu_index, qemu_plugin_meminfo_t info, + uint64_t vaddr, void *udata) +{} + + +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) +{ + struct qemu_plugin_insn *insn; + size_t n = qemu_plugin_tb_n_insns(tb); + + for (size_t i = 0; i < n; i++) { + insn = qemu_plugin_tb_get_insn(tb, i); + + /* Register callback on memory read or write */ + qemu_plugin_register_vcpu_mem_cb(insn, vcpu_mem, + QEMU_PLUGIN_CB_NO_REGS, + QEMU_PLUGIN_MEM_R, NULL); + } +} + +QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id, + const qemu_info_t *info, int argc, + char **argv) +{ + qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans); + + return 0; +} +``` +Steps to reproduce: +1. From the current head of `master` (a66f28df650166ae8b50c992eea45e7b247f4143) +2. Add the above plugin to the contrib/plugins directory and update the `contrib/plugins/Makefile` with `NAMES += customtest` so it will be built. +3. `../configure --enable-plugins --target-list=x86_64-softmmu` +4. `make && make plugins` +5. `wget https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2` +6. Launch the guest with `./qemu-system-x86_64 -m 1G -plugin contrib/plugins/libcustomtest.so bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2 -nographic -d plugin`, and wait a moment. There will be no output after the initial "Booting from Hard Disk" mesasge. Switch to the monitor with `ctrl+a c` type `quit` and press enter, qemu fails to exit because of the deadlock. +Additional information: +* I tested and saw the bug on the following commits/tags: current head of master (a66f28df650166ae8b50c992eea45e7b247f4143), v9.1.0, v9.0.0, and v8.2.6, v8.1.0. +* I tested and saw no bug on the following tags: v8.0.5, v8.0.4, v8.0.0 +* If `qemu_plugin_register_vcpu_mem_cb` is called with a fourth argument of `0` instead of `QEMU_PLUGIN_MEM_R`, the guest did not hang (at least on the current head of master). +* The monitor can still be reached with `ctrl+a c` after the deadlock, but running the `quit` command does not terminate the emulator (I don't think this is related to #1195 since things start hanging before the shutdown begins) + +Gdb shows the following backtraces (from the head of master) across the running threads. It seems that thread 3 and thread 2 are stuck, though I'm not too familiar with what they're doing. +``` +(gdb) thread apply all bt + +Thread 3 (Thread 0x7f9677fff640 (LWP 754761) "qemu-system-x86"): +#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55a9c1047748 <exclusive_cond+40>) at ./nptl/futex-internal.c:57 +#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55a9c1047748 <exclusive_cond+40>) at ./nptl/futex-internal.c:87 +#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55a9c1047748 <exclusive_cond+40>, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 +#3 0x00007f968280aa41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55a9c1047660 <qemu_cpu_list_lock>, cond=0x55a9c1047720 <exclusive_cond>) at ./nptl/pthread_cond_wait.c:503 +#4 ___pthread_cond_wait (cond=cond@entry=0x55a9c1047720 <exclusive_cond>, mutex=mutex@entry=0x55a9c1047660 <qemu_cpu_list_lock>) at ./nptl/pthread_cond_wait.c:627 +#5 0x000055a9bff8ce9f in qemu_cond_wait_impl (cond=0x55a9c1047720 <exclusive_cond>, mutex=0x55a9c1047660 <qemu_cpu_list_lock>, file=0x55a9bffc37b6 "../cpu-common.c", line=221) at ../util/qemu-thread-posix.c:225 +#6 0x000055a9bf8fc7b7 in start_exclusive () at ../cpu-common.c:221 +#7 start_exclusive () at ../cpu-common.c:192 +#8 0x000055a9bfc2f981 in ptw_setl_slow (new=23069091, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:112 +#9 ptw_setl (set=<optimized out>, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:130 +#10 ptw_setl (set=<optimized out>, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:121 +#11 mmu_translate (env=env@entry=0x55a9c2ab3bc0, in=in@entry=0x7f9677ffa5f0, out=out@entry=0x7f9677ffa5c0, err=err@entry=0x7f9677ffa5d0, ra=ra@entry=140283034940586) at ../target/i386/tcg/sysemu/excp_helper.c:412 +#12 0x000055a9bfc2fe4f in get_physical_address (ra=<optimized out>, err=<optimized out>, out=<optimized out>, mmu_idx=<optimized out>, access_type=<optimized out>, addr=25041848, env=<optimized out>) at ../target/i386/tcg/sysemu/excp_helper.c:583 +#13 x86_cpu_tlb_fill (cs=0x55a9c2ab1400, addr=25041848, size=<optimized out>, access_type=MMU_DATA_LOAD, mmu_idx=5, probe=<optimized out>, retaddr=140283034940586) at ../target/i386/tcg/sysemu/excp_helper.c:603 +#14 0x000055a9bfd92a59 in tlb_fill (retaddr=140283034940586, mmu_idx=5, access_type=MMU_DATA_LOAD, size=<optimized out>, addr=25041848, cpu=0x55a9c2ab1450) at ../accel/tcg/cputlb.c:1237 +#15 mmu_lookup1 (cpu=cpu@entry=0x55a9c2ab1400, data=data@entry=0x7f9677ffa750, mmu_idx=5, access_type=access_type@entry=MMU_DATA_LOAD, ra=ra@entry=140283034940586) at ../accel/tcg/cputlb.c:1634 +#16 0x000055a9bfd92b71 in mmu_lookup (cpu=cpu@entry=0x55a9c2ab1400, addr=addr@entry=25041848, oi=oi@entry=37, ra=ra@entry=140283034940586, type=type@entry=MMU_DATA_LOAD, l=l@entry=0x7f9677ffa750) at ../accel/tcg/cputlb.c:1724 +#17 0x000055a9bfd937b0 in do_ld4_mmu (cpu=cpu@entry=0x55a9c2ab1400, addr=addr@entry=25041848, oi=oi@entry=37, ra=140283034940586, ra@entry=37, access_type=access_type@entry=MMU_DATA_LOAD) at ../accel/tcg/cputlb.c:2356 +#18 0x000055a9bfd96afa in cpu_ldl_mmu (ra=37, oi=37, addr=25041848, env=0x55a9c2ab3bc0) at ../accel/tcg/ldst_common.c.inc:160 +#19 cpu_ldl_le_mmuidx_ra (env=env@entry=0x55a9c2ab3bc0, addr=25041848, mmu_idx=mmu_idx@entry=5, ra=ra@entry=140283034940586) at ../accel/tcg/ldst_common.c.inc:298 +#20 0x000055a9bfc9a639 in popl (sa=<synthetic pointer>) at ../target/i386/tcg/seg_helper.c:88 +#21 helper_ret_protected (env=0x55a9c2ab3bc0, shift=1, is_iret=0, addend=0, retaddr=140283034940586) at ../target/i386/tcg/seg_helper.c:2031 +#22 0x00007f96307734aa in code_gen_buffer () +#23 0x000055a9bfd855f6 in cpu_tb_exec (cpu=cpu@entry=0x55a9c2ab1400, itb=itb@entry=0x7f96307733c0 <code_gen_buffer+7811987>, tb_exit=tb_exit@entry=0x7f9677ffadd8) at ../accel/tcg/cpu-exec.c:458 +#24 0x000055a9bfd85b4c in cpu_loop_exec_tb (tb_exit=0x7f9677ffadd8, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7f96307733c0 <code_gen_buffer+7811987>, cpu=0x55a9c2ab1400) at ../accel/tcg/cpu-exec.c:908 +#25 cpu_exec_loop (cpu=cpu@entry=0x55a9c2ab1400, sc=sc@entry=0x7f9677ffae70) at ../accel/tcg/cpu-exec.c:1022 +#26 0x000055a9bfd86351 in cpu_exec_setjmp (cpu=cpu@entry=0x55a9c2ab1400, sc=sc@entry=0x7f9677ffae70) at ../accel/tcg/cpu-exec.c:1039 +#27 0x000055a9bfd86b0e in cpu_exec (cpu=cpu@entry=0x55a9c2ab1400) at ../accel/tcg/cpu-exec.c:1065 +#28 0x000055a9bfdaafa4 in tcg_cpu_exec (cpu=cpu@entry=0x55a9c2ab1400) at ../accel/tcg/tcg-accel-ops.c:78 +#29 0x000055a9bfdab0ff in mttcg_cpu_thread_fn (arg=arg@entry=0x55a9c2ab1400) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#30 0x000055a9bff8c2d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 +#31 0x00007f968280bac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#32 0x00007f968289d850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 + +Thread 2 (Thread 0x7f967d990640 (LWP 754759) "qemu-system-x86"): +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055a9bff8d5b2 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /home/user/git/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=ev@entry=0x55a9c1079588 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:464 +#3 0x000055a9bff97d82 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:278 +#4 0x000055a9bff8c2d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 +#5 0x00007f968280bac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#6 0x00007f968289d850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 + +Thread 1 (Thread 0x7f967dc035c0 (LWP 754758) "qemu-system-x86"): +#0 0x00007f968288fcce in __ppoll (fds=0x55a9c382dd00, nfds=5, timeout=<optimized out>, timeout@entry=0x7ffeadbd44d0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42 +#1 0x000055a9bffa4e05 in ppoll (__ss=0x0, __timeout=0x7ffeadbd44d0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:64 +#2 qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=54822346) at ../util/qemu-timer.c:351 +#3 0x000055a9bffa1ed6 in os_host_main_loop_wait (timeout=54822346) at ../util/main-loop.c:305 +#4 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:589 +#5 0x000055a9bfb47217 in qemu_main_loop () at ../system/runstate.c:826 +#6 0x000055a9bfee421b in qemu_default_main () at ../system/main.c:37 +#7 0x00007f96827a0d90 in __libc_start_call_main (main=main@entry=0x55a9bf8f9790 <main>, argc=argc@entry=9, argv=argv@entry=0x7ffeadbd46e8) at ../sysdeps/nptl/libc_start_call_main.h:58 +#8 0x00007f96827a0e40 in __libc_start_main_impl (main=0x55a9bf8f9790 <main>, argc=9, argv=0x7ffeadbd46e8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffeadbd46d8) at ../csu/libc-start.c:392 +#9 0x000055a9bf8fa7b5 in _start () +``` diff --git a/results/classifier/zero-shot/108/none/2567 b/results/classifier/zero-shot/108/none/2567 new file mode 100644 index 000000000..f3758f3e9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2567 @@ -0,0 +1,93 @@ +permissions: 0.517 +KVM: 0.514 +other: 0.505 +PID: 0.505 +performance: 0.496 +device: 0.474 +semantic: 0.467 +graphic: 0.455 +boot: 0.453 +vnc: 0.432 +files: 0.389 +debug: 0.376 +network: 0.343 +socket: 0.323 + +crash in target/i386/tcg/translate.c on loongarch64 Linux debian 6.11.0-rc7 +Description of problem: +``` + ERROR:target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached + Bail out! ERROR:target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached + 已中止（核心已转储） + ``` +Steps to reproduce: +1. windows x64 has been installed into win7_x64.qcow2 +2. windows x64 in win7_x64.qcow2 has been run for several times by the same command line +3. crash occurred when windows was starting up +Additional information: +``` +Hint: You are currently not seeing messages from other users and the system. + Users in groups 'adm', 'systemd-journal' can see all messages. + Pass -q to turn off this notice. + PID: 61627 (qemu-system-x86) + UID: 1000 (tsingkong) + GID: 1001 (tsingkong) + Signal: 6 (ABRT) + Timestamp: Tue 2024-09-10 15:59:05 CST (18h ago) + Command Line: qemu-system-x86_64 -name win7_x64 -hda /SATA/QEMU/win7_x64.qcow2 -boot c -cpu qemu64 -smp sockets=1,cores=4,threads=1 -m 8G -device VGA -netdev user,id=lan -device rtl8139,netdev=lan -usb -device usb-tablet -rtc base=localtime -monitor stdio + Executable: /usr/bin/qemu-system-x86_64 + Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-353cf168c0a84fbe8cdc2b8b72cba71e.scope + Unit: user@1000.service + User Unit: app-org.kde.konsole-353cf168c0a84fbe8cdc2b8b72cba71e.scope + Slice: user-1000.slice + Owner UID: 1000 (tsingkong) + Boot ID: 49cf5288d7af4b97be341fe599f0c8df + Machine ID: 3ab0590011874c2e916d2eeef4585dfb + Hostname: debian + Storage: /var/lib/systemd/coredump/core.qemu-system-x86.1000.49cf5288d7af4b97be341fe599f0c8df.61627.1725955145000000.zst (present) + Size on Disk: 285.9M + Message: Process 61627 (qemu-system-x86) of user 1000 dumped core. + + Module libsystemd.so.0 from deb systemd-256.5-2.loong64 + Module libgcc_s.so.1 from deb gcc-14-14.2.0-4.loong64 + Module libstdc++.so.6 from deb gcc-14-14.2.0-4.loong64 + Module libblkid.so.1 from deb util-linux-2.40.2-8.loong64 + Module libatomic.so.1 from deb gcc-14-14.2.0-4.loong64 + Module libmount.so.1 from deb util-linux-2.40.2-8.loong64 + Module libzstd.so.1 from deb libzstd-1.5.6+dfsg-1.loong64 + Module libudev.so.1 from deb systemd-256.5-2.loong64 + Stack trace of thread 61637: + #0 0x00007ffff2536968 __pthread_kill_implementation (libc.so.6 + 0x76968) + #1 0x00007ffff24f17dc __GI_raise (libc.so.6 + 0x317dc) + #2 0x00007ffff24dd238 __GI_abort (libc.so.6 + 0x1d238) + #3 0x00007ffff2ccf704 g_assertion_message (libglib-2.0.so.0 + 0x93704) + #4 0x00007ffff2ccf768 g_assertion_message_expr (libglib-2.0.so.0 + 0x93768) + #5 0x000055555630c440 n/a (qemu-system-x86_64 + 0x830440) + #6 0x00005555563286e8 n/a (qemu-system-x86_64 + 0x84c6e8) + #7 0x000055555632ef0c n/a (qemu-system-x86_64 + 0x852f0c) + #8 0x00005555563f9108 translator_loop (qemu-system-x86_64 + 0x91d108) + #9 0x0000555556332474 gen_intermediate_code (qemu-system-x86_64 + 0x856474) + #10 0x00005555563f7c08 n/a (qemu-system-x86_64 + 0x91bc08) + #11 0x00005555563f8204 tb_gen_code (qemu-system-x86_64 + 0x91c204) + #12 0x00005555563ecd54 n/a (qemu-system-x86_64 + 0x910d54) + #13 0x00005555563ed288 n/a (qemu-system-x86_64 + 0x911288) + #14 0x00005555563edb98 cpu_exec (qemu-system-x86_64 + 0x911b98) + #15 0x00007fffdc006c5c tcg_cpu_exec (accel-tcg-x86_64.so + 0x2c5c) + #16 0x00007fffdc006df4 n/a (accel-tcg-x86_64.so + 0x2df4) + #17 0x0000555556636000 n/a (qemu-system-x86_64 + 0xb5a000) + #18 0x00007ffff2534ca4 start_thread (libc.so.6 + 0x74ca4) + #19 0x00007ffff259cbcc __thread_start3 (libc.so.6 + 0xdcbcc) + + Stack trace of thread 61640: + #0 0x00005555563fd620 n/a (qemu-system-x86_64 + 0x921620) + #1 0x0000555556401b44 get_page_addr_code_hostp (qemu-system-x86_64 + 0x925b44) + #2 0x00005555563ebda8 n/a (qemu-system-x86_64 + 0x90fda8) + #3 0x00005555563ed5f0 helper_lookup_tb_ptr (qemu-system-x86_64 + 0x9115f0) + #4 0x00007fff8d39309c n/a (n/a + 0x0) + ELF object binary architecture: LoongArch + +``` + +core.qemu-system-x86.1000.49cf5288d7af4b97be341fe599f0c8df.61627.1725955145000000.zst + +https://mega.nz/file/M9ZVzQYS#Z8kw6_cul56nd_p2iwz2SRb4Yb_1K8gqH2YlBBjKk6U diff --git a/results/classifier/zero-shot/108/none/257 b/results/classifier/zero-shot/108/none/257 new file mode 100644 index 000000000..636eadadf --- /dev/null +++ b/results/classifier/zero-shot/108/none/257 @@ -0,0 +1,16 @@ +device: 0.465 +network: 0.361 +files: 0.354 +debug: 0.291 +graphic: 0.265 +semantic: 0.240 +performance: 0.196 +PID: 0.191 +boot: 0.158 +permissions: 0.143 +vnc: 0.071 +other: 0.054 +socket: 0.019 +KVM: 0.003 + +[Archlinux][git]With git revision e58c7a3b, packaging with meson install is broken. diff --git a/results/classifier/zero-shot/108/none/2588 b/results/classifier/zero-shot/108/none/2588 new file mode 100644 index 000000000..e1aa58306 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2588 @@ -0,0 +1,58 @@ +performance: 0.414 +device: 0.408 +graphic: 0.306 +vnc: 0.234 +socket: 0.227 +semantic: 0.216 +PID: 0.208 +network: 0.178 +other: 0.170 +files: 0.169 +boot: 0.143 +permissions: 0.133 +KVM: 0.103 +debug: 0.087 + +qemu-system-arm regression: NonSecure World can change Secure World MMU mapping. +Description of problem: +A NonSecure execution context is able to override MMU L1 translation table +flags set by Secure context on Secure World memory. + +This is not consistent with the same code running on real hardware and it's a +regression over past qemu releases as 9.0.0 behaves correctly. +Steps to reproduce: +This has been tested with +[GoTEE-example](https://github.com/usbarmory/GoTEE-example) as follows: + +``` +# building tamago +wget https://github.com/usbarmory/tamago-go/archive/refs/tags/latest.zip +unzip latest.zip +cd tamago-go-latest/src && ./all.bash +cd ../bin && export TAMAGO=`pwd`/go + +# building and running GoTEE-example +wget https://github.com/usbarmory/GoTEE-example/archive/refs/heads/master.zip +unzip master.zip +cd GoTEE-example +export TARGET=usbarmory && make clean && make nonsecure_os_go && make trusted_applet_go && make trusted_os && make qemu +``` + +# +Additional information: +The issue relates to the fact that the NonSecure World, at startup, configures +the MMU with the NX bit for the entire address space not belonging to its +firmware .text area. + +On real hardware this MMU configuration by NonSecure world does not affect the +Secure World translation tables. + +On qemu 9.1.0, however it does and this is inconsistent with real hardware +behavior. On qemu 9.0.0 the behaviour is correct so the issue has been +introduced between these two releases. + +The switch between Secure and NonSecure is done +[here](https://github.com/usbarmory/GoTEE/blob/7e62563c0628fed3ee0aebb4702e22be9bb636e3/monitor/exec_arm.s#L73). + +The MMU first level address table which sets the NX bit is done +[here](https://github.com/usbarmory/tamago/blob/273d67cd811dfcb1782c0fe596ac14d43d0ce117/arm/mmu.go#L85). diff --git a/results/classifier/zero-shot/108/none/2590 b/results/classifier/zero-shot/108/none/2590 new file mode 100644 index 000000000..642fac1a8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2590 @@ -0,0 +1,38 @@ +device: 0.101 +graphic: 0.092 +debug: 0.037 +permissions: 0.033 +semantic: 0.030 +PID: 0.030 +other: 0.028 +vnc: 0.013 +socket: 0.013 +performance: 0.011 +boot: 0.010 +network: 0.007 +files: 0.003 +KVM: 0.001 + +qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries. +Description of problem: +GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work. +Steps to reproduce: +1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary` +2. Connect GDB to the debug server: +``` +$ gdb-multiarch ./x86_64-binary +(gdb) set verbose on +(gdb) target remote :PORT +``` +3. GDB displays a warning and fails to load shared libraries: +``` +(gdb) target remote :PORT +Remote debugging using :PORT +warning: platform-specific solib_create_inferior_hook did not load initial shared libraries. +(gdb) info sharedlibrary +No shared libraries loaded at this time. +``` +Additional information: +This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. + +GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected. diff --git a/results/classifier/zero-shot/108/none/2603 b/results/classifier/zero-shot/108/none/2603 new file mode 100644 index 000000000..6fd903a38 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2603 @@ -0,0 +1,117 @@ +other: 0.593 +graphic: 0.583 +semantic: 0.570 +permissions: 0.566 +debug: 0.535 +PID: 0.530 +vnc: 0.523 +device: 0.515 +performance: 0.514 +network: 0.489 +files: 0.486 +socket: 0.469 +KVM: 0.436 +boot: 0.417 + +Recent libslirp commit broke Qemu network stack: qemu and libslirp teams should settle on SOCKET handler type +Description of problem: +https://gitlab.freedesktop.org/slirp/libslirp/-/commit/72f85005a2307fd0961543e3cea861ad7a4d201e introduced regression causing QEMU compilation for Windows to error out due to missing 64-bit SOCKET handler pointer type. + +``` +x86_64-w64-mingw32-gcc -m64 ... -MD -MQ libcommon.a.p/net_slirp.c.obj -MF libcommon.a.p/net_slirp.c.obj.d -o libcommon.a.p/net_slirp.c.obj -c ../net/slirp.c +../net/slirp.c:289:25: error: initialization of 'void (*)(slirp_os_socket, void *)' {aka 'void (*)(long long unsigned int, void *)'} from incompatible pointer type 'void (*)(int, void *)' [-Wincompatible-pointer-types] + 289 | .register_poll_fd = net_slirp_register_poll_fd, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +../net/slirp.c:289:25: note: (near initialization for 'slirp_cb.register_poll_fd') +../net/slirp.c:290:27: error: initialization of 'void (*)(slirp_os_socket, void *)' {aka 'void (*)(long long unsigned int, void *)'} from incompatible pointer type 'void (*)(int, void *)' [-Wincompatible-pointer-types] + 290 | .unregister_poll_fd = net_slirp_unregister_poll_fd, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../net/slirp.c:290:27: note: (near initialization for 'slirp_cb.unregister_poll_fd') +../net/slirp.c: In function 'net_slirp_poll_notify': +../net/slirp.c:367:28: error: passing argument 3 of 'slirp_pollfds_fill' from incompatible pointer type [-Wincompatible-pointer-types] + 367 | net_slirp_add_poll, poll->pollfds); + | ^~~~~~~~~~~~~~~~~~ + | | + | int (*)(int, int, void *) +In file included from ../net/slirp.c:41: +/home/cross-qemu-deps/include/slirp/libslirp.h:255:40: note: expected 'SlirpAddPollCb' {aka 'int (*)(long long unsigned int, int, void *)'} but argument is of type 'int (*)(int, int, void *)' + 255 | SlirpAddPollCb add_poll, void *opaque); + | ~~~~~~~~~~~~~~~^~~~~~~~ +``` + +Possible solution relying on cross-platform MACRO: https://handsonnetworkprogramming.com/articles/socket-function-return-value-windows-linux-macos/ +Steps to reproduce: +1. Prepare cross-compilation build of qemu 9.1.0 using following steps (It's not necessary to set up a virtual machine if your main OS has good mingw repository, like Fedora, Arch linux, Manjaro. But if you're on Debian or Ubuntu, it's required): +2. Download official Fedora workstation 40 x86_64 ISO and install it to a virtual disk and boot that disk. +3. On Fedora, do:\ + `wget https://download.qemu.org/qemu-9.1.0.tar.xz`\ + ` tar xvJf qemu-9.1.0.tar.xz`\ + ` cd qemu-9.1.0` +4. `sudo yum install git meson ninja-build python3-sphinx python3-sphinx_rtd_theme gcc mingw64-gcc mingw64-pkg-config mingw64-glib2` +5. `git clone https://gitlab.freedesktop.org/slirp/libslirp.git` +6. create file x86_64-w64-mingw32.txt in qemu-9.1.0 directory with the content as follows: + +``` +[binaries] +c = '/usr/bin/x86_64-w64-mingw32-gcc' +cpp = '/usr/bin/x86_64-w64-mingw32-g++' +ar = '/usr/bin/x86_64-w64-mingw32-ar' +strip = '/usr/bin/x86_64-w64-mingw32-strip' +pkg-config = '/usr/bin/x86_64-w64-mingw32-pkg-config' +exe_wrapper = 'wine' + +[host_machine] +system = 'windows' +cpu_family = 'x86_64' +cpu = 'i686' +endian = 'little' +``` + + 7. Run 2 commands: + + `export CROSS_QEMU_DEPS="/home/cross-qemu-deps"`\ + ` sudo mkdir -p $CROSS_QEMU_DEPS` + 8. Install libslirp so that future qemu binaries can have internet access via \`-netdev user\`\ + \ + `cd libslirp`\ + \ + ` meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/`\ + ` meson compile -C build-mingw`\ + ` cd build-mingw`\ + ` ninja install` + 9. Set environment variables for cross-compilation\ + \ + ` sudo find / -type f -name '*.pc'` and make sure all mingw \*.pc files live in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/. Correct this path in PKG_CONFIG_PATH if you see it was altered by mingw or package contributors.\ + \ + ` export PKG_CONFIG_PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/:$PKG_CONFIG_PATH"`\ + ` export PKG_CONFIG_LIBDIR="${CROSS_QEMU_DEPS}/lib/pkgconfig/:$PKG_CONFIG_LIBDIR"`\ + ` export PKG_CONFIG_SYSROOT_DIR=""` +10. Configure Qemu makefile:\ + \ + `cd ../../`\ + `./configure --cross-prefix=x86_64-w64-mingw32- --enable-slirp`\ + \ + and make sure you see this in the output of configure:\ + `Compilation`\ + `host CPU : x86_64`\ + `host endianness : little`\ + `C compiler : x86_64-w64-mingw32-gcc -m64`\ + `Host C compiler : cc` +11. Cross-compile qemu: `` make -j`nproc` `` +12. Get the error `initialization of 'void (*)(slirp_os_socket, void *)' {aka 'void (*)(long long unsigned int, void *)'} from incompatible pointer type 'void (*)(int, void *)'` as above. +Additional information: +After having seen this bug, do these steps (revert to the commit right before the buggy one). + +` cd libslirp`\ +` git reset --hard 5e97a93b` + +` meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/ --reconfigure`\ +` meson compile -C build-mingw`\ +` cd build-mingw`\ +` ninja install` + +`` cd ../../ ``\ +`` ./configure --cross-prefix=x86_64-w64-mingw32- --enable-slirp ``\ +`` make -j`nproc` `` + +=\> Cross-compilation comes to an end just fine, building all compilation targets without any errors. diff --git a/results/classifier/zero-shot/108/none/2613 b/results/classifier/zero-shot/108/none/2613 new file mode 100644 index 000000000..e4bf07d73 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2613 @@ -0,0 +1,16 @@ +device: 0.514 +PID: 0.351 +graphic: 0.307 +semantic: 0.269 +debug: 0.211 +other: 0.142 +performance: 0.136 +boot: 0.135 +network: 0.129 +socket: 0.082 +vnc: 0.064 +permissions: 0.056 +files: 0.045 +KVM: 0.001 + +I was trying to build QEMU from source(noble) using debian commands in ubuntu24.04 derived docker and I got this error: cc1: error: ‘-fcf-protection’ is not compatible with this target diff --git a/results/classifier/zero-shot/108/none/2618 b/results/classifier/zero-shot/108/none/2618 new file mode 100644 index 000000000..57a4fd530 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2618 @@ -0,0 +1,16 @@ +graphic: 0.557 +performance: 0.490 +semantic: 0.440 +device: 0.273 +permissions: 0.125 +boot: 0.108 +socket: 0.070 +debug: 0.054 +files: 0.039 +network: 0.034 +vnc: 0.030 +other: 0.029 +KVM: 0.025 +PID: 0.020 + +INTEGER_OVERFLOW in sparc.c diff --git a/results/classifier/zero-shot/108/none/2641 b/results/classifier/zero-shot/108/none/2641 new file mode 100644 index 000000000..5332e17f7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2641 @@ -0,0 +1,16 @@ +graphic: 0.349 +semantic: 0.242 +device: 0.234 +performance: 0.202 +other: 0.089 +vnc: 0.050 +permissions: 0.043 +KVM: 0.041 +socket: 0.040 +network: 0.025 +PID: 0.020 +boot: 0.017 +debug: 0.012 +files: 0.010 + +Possible DEREF_OF_NULL in linux-user/syscall.c diff --git a/results/classifier/zero-shot/108/none/2648 b/results/classifier/zero-shot/108/none/2648 new file mode 100644 index 000000000..8a66b8aec --- /dev/null +++ b/results/classifier/zero-shot/108/none/2648 @@ -0,0 +1,26 @@ +graphic: 0.580 +device: 0.525 +semantic: 0.439 +network: 0.342 +vnc: 0.315 +performance: 0.295 +other: 0.132 +debug: 0.124 +boot: 0.121 +socket: 0.111 +KVM: 0.084 +permissions: 0.056 +files: 0.056 +PID: 0.041 + +Possible dereference of NULL in block/qapi.c +Description of problem: +qdict_get can return NULL if the "data" key is not found in the obj dictionary. Then if NULL is passed to the qobject_is_empty_dump function, it will be dereferenced when calling the qobject_type function. + +https://github.com/qemu/qemu/blob/92ec7805190313c9e628f8fc4eb4f932c15247bd/block/qapi.c#L891-L892 + +I think that data check for NULL should be added. + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Burke. diff --git a/results/classifier/zero-shot/108/none/2649 b/results/classifier/zero-shot/108/none/2649 new file mode 100644 index 000000000..67eae5600 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2649 @@ -0,0 +1,55 @@ +semantic: 0.085 +files: 0.076 +device: 0.074 +performance: 0.066 +graphic: 0.059 +PID: 0.053 +network: 0.045 +other: 0.044 +permissions: 0.036 +boot: 0.033 +debug: 0.033 +vnc: 0.029 +socket: 0.025 +KVM: 0.008 + +Data corruption with qcow2 images +Steps to reproduce: +``` +# Create an example file with old version of qemu-img and fill it with random data. +$ qemu-img-8.2.2 create -f qcow2 file.qcow2 600000000000 +$ qemu-nbd-8.2.2 -c /dev/nbd0 file.qcow2 +$ dd if=/dev/random of=/dev/nbd0 bs=1000000 count=600000 +$ qemu-nbd-8.2.2 -d /dev/nbd0 +/dev/nbd0 disconnected + +# Get the correct checksum of both qcow2 file and its contents +$ sha256sum -b file.qcow2 +ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2 +$ qemu-nbd-8.2.2 -r -c /dev/nbd0 file.qcow2 +$ sha256sum -b /dev/nbd0 +5dac11e88f891740da3b655588b2e62037962d1ba6377efce30124d6224dd0d1 */dev/nbd0 +$ qemu-nbd-8.2.2 -d /dev/nbd0 +/dev/nbd0 disconnected + +# Use the qcow2 file with new version. +# We're using qemu-nbd here, but the same happens when qcow2 is attached to a guest +# running in the new version qemu-system-86_64-9.1.1 and can be seen through guest's +# /dev/vda. +# Note that the checksum is different than before, and also non-deterministic +# (running sha256sum twice produces different results even though the file is +# read-only and hasn't changed). +$ sha256sum -b file.qcow2 +ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2 +$ qemu-nbd-9.1.1 -r -c /dev/nbd0 file.qcow2 +$ sha256sum -b /dev/nbd0 +1793a38b9b964d3fc643629284722373e9d5dedea68e35900ace777b57688926 */dev/nbd0 +$ sha256sum -b /dev/nbd0 +98f900f9cd174493d0bfcf06e2bc86f5ee99dfa04c90d6832fa941e384b62d49 */dev/nbd0 +$ qemu-nbd-9.1.1 -d /dev/nbd0 +/dev/nbd0 disconnected +$ sha256sum -b file.qcow2 +ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2 +``` +Additional information: +No errors in either host or guest logs. When using a qcow2 with an actual filesystem, you may see reports of corruption from the filesystem driver. diff --git a/results/classifier/zero-shot/108/none/2650 b/results/classifier/zero-shot/108/none/2650 new file mode 100644 index 000000000..8b41f08d1 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2650 @@ -0,0 +1,207 @@ +permissions: 0.598 +performance: 0.558 +KVM: 0.548 +other: 0.538 +debug: 0.528 +device: 0.506 +semantic: 0.491 +PID: 0.490 +graphic: 0.490 +boot: 0.486 +files: 0.468 +socket: 0.465 +vnc: 0.464 +network: 0.443 + +qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed +Description of problem: +If a named dirty bitmap already exists on a disk and another disk is added via hotplug after the guest has booted, it will definitely cause the hot migration to fail. +Steps to reproduce: +1. Create 2 images of type qcow2 + + ``` + qemu-img create -f qcow2 vda.qcow2 50G + qemu-img create -f qcow2 vdb.qcow2 2G # set to 2G + ``` +2. Start the guest using the following libvirt xml + + ``` + # virsh create i-btacsctt.xml + + <domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm"> + <name>i-btacsctt</name> + <uuid>973f7352-ad1d-31ea-9a9f-237f3e9a384f</uuid> + <memory unit="MiB">2048</memory> + <vcpu current="2">2</vcpu> + <os> + <type arch="x86_64" machine="pc">hvm</type> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <devices> + <emulator>/opt/qemu-5.1.0.9/usr/bin/qemu-system-x86_64</emulator> + <disk device="disk" type="file"> + <driver cache="writeback" discard="ignore" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vda.qcow2"/> + <target dev="vda"/> + </disk> + <disk device="disk" type="file"> + <driver cache="none" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vdb.qcow2"/> + <target dev="vdb"/> + </disk> + </devices> + </domain> + ``` +3. Create bitmap for vda + + ``` + # The node name of vda is "libvirt-2-format" + virsh qemu-monitor-command i-btacsctt --hmp "info block" + libvirt-2-format: /tmp/echohu3/vda.qcow2 (qcow2) + Attached to: /machine/peripheral/virtio-disk0/virtio-backend + Cache mode: writethrough + + libvirt-1-format: /tmp/echohu3/vdb.qcow2 (qcow2) + Attached to: /machine/peripheral/virtio-disk1/virtio-backend + Cache mode: writeback, direct + + # Create bitmap + virsh qemu-monitor-command i-btacsctt '{"execute":"block-dirty-bitmap-add","arguments":{"node":"libvirt-2-format","name":"bitmap0","persistent":true}}' + ``` +4. Create vdc and run hotpluggin + + ``` + qemu-img create -f qcow2 vdc.qcow2 50G + + cat disk.xml + <disk device="disk" type="file"> + <driver cache="none" discard="ignore" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vdc.qcow2"/> + <target dev="vdc"/> + </disk> + + virsh attach-device i-btacsctt disk.xml + ``` +5. Start live migrationg + + ``` + # scp *.qcow2 172.31.68.42:/tmp/echohu3/ + virsh qemu-monitor-command i-btacsctt --hmp "migrate_set_capability dirty-bitmaps on" + virsh dumpxml --migratable i-btacsctt >/tmp/ivm-btacsctt.xml + virsh migrate --live --abort-on-error --xml /tmp/ivm-btacsctt.xml i-btacsctt qemu+tcp://172.31.68.42/system + error: internal error: qemu unexpectedly closed the monitor: qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed. + ``` +Additional information: +Set breakpoints on the source side + +``` +gdb -p $pid -ex "break add_bitmaps_to_list" -ex "handle SIGUSR1 nostop" -ex "continue" +(gdb) bt +#0 add_bitmaps_to_list (bs=bs@entry=0x55c5bbaf85d0, bs_name=0x55c5bbafc674 "libvirt-2-format", alias_map=alias_map@entry=0x0, s=<optimized out>) at migration/block-dirty-bitmap.c:502 +#1 0x000055c5ba3b2878 in init_dirty_bitmap_migration (s=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:660 +#2 dirty_bitmap_save_setup (f=0x55c5bc981c40, opaque=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:1226 +#3 0x000055c5ba3a3c4d in qemu_savevm_state_setup (f=0x55c5bc981c40) at migration/savevm.c:1176 +#4 0x000055c5ba39e16b in migration_thread (opaque=opaque@entry=0x55c5bbaa2400) at migration/migration.c:3487 +#5 0x000055c5ba530cf3 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#6 0x00007f39846d9609 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#7 0x00007f3983d11293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +(gdb) p bs->node_name +$4 = "libvirt-2-format", '\000' <repeats 15 times> +(gdb) p bitmap->name +$5 = 0x55c5bbaf13d0 "bitmap0" +``` + +Set a breakpoint on the target side after hitting the breakpoint on the source side. + +``` +gdb -p $pid -ex "break serialization_chunk if ((start + count - 1) >> hb->granularity) >= hb->size" -ex "break dirty_bitmap_load_header" -ex "handle SIGUSR1 nostop" -ex "continue" +(gdb) bt +#0 dirty_bitmap_load_header (alias_map=0x0, s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:1146 +#1 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1187 +#2 0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883 +#3 vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879 +#4 0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365 +#5 qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518 +#6 0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590 +#7 0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480 +#8 0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173 +#9 0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +``` + +in dirty_bitmap_load_header + +``` +s->bs = bdrv_lookup_bs(s->node_name, s->node_name, &local_err); // node_name is "libvirt-2-format" +s->bitmap = bdrv_find_dirty_bitmap(s->bs, s->bitmap_name); // bitmap_name is "bitmap0" + +# Target side: “libvirt-2-format” is the node name of vdb. +(gdb) p s->bs->node_name +$10 = "libvirt-2-format", '\000' <repeats 15 times> +(gdb) p s->bs->filename +$11 = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times> +``` + +We can also see from the target /var/log/libvirt/qemu/i-btacsctt.log file that “libvirt-2-format” is the node name of the vdb，while the node name of vda is libvirt-3-format. + +``` +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vda.qcow2","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":false,"discard":"ignore","cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x2,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdb.qcow2","aio":"threads","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-2-format,id=virtio-disk1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdc.qcow2","aio":"threads","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"discard":"ignore","cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +``` + +From the source code, we know that HBitmap.size is from vdb size (2G), but bitmap is from vda (50G), so it triggers assert exception in serialization_chunk. + +``` +(gdb) bt +#0 serialization_chunk (hb=hb@entry=0x55748ba28470, start=2147483648, count=536870912, first_el=first_el@entry=0x7f53503ffd20, el_count=el_count@entry=0x7f53503ffd18) at util/hbitmap.c:610 +#1 0x0000557487f18654 in hbitmap_deserialize_zeroes (hb=0x55748ba28470, start=start@entry=2147483648, count=count@entry=536870912, finish=finish@entry=false) at util/hbitmap.c:701 +#2 0x0000557487e7cfb0 in bdrv_dirty_bitmap_deserialize_zeroes (bitmap=<optimized out>, offset=offset@entry=2147483648, bytes=bytes@entry=536870912, finish=finish@entry=false) at block/dirty-bitmap.c:749 +#3 0x0000557487d86b51 in dirty_bitmap_load_bits (s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:992 +#4 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198 +#5 0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883 +#6 vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879 +#7 0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365 +#8 qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518 +#9 0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590 +#10 0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480 +#11 0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173 +#12 0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +#13 0x00007ffffb29c410 in () +#14 0x0000000000000000 in () +(gdb) p *hb +$16 = {orig_size = 2147483648, size = 32768, count = 0, granularity = 16, meta = 0x0, levels = {0x55748ad55ad0, 0x55748acd8df0, 0x55748b0866a0, 0x55748acf8c10, 0x55748b1c4180, 0x55748b154f60, 0x55748adf2370}, sizes = {1, 1, 1, 1, 1, 8, + 512}} +``` + +``` +(gdb) f 4 +#4 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198 +(gdb) p *s->bs +$21 = {open_flags = 10274, read_only = false, encrypted = false, sg = false, probed = false, force_share = false, implicit = false, drv = 0x557488aa2ee0 <bdrv_qcow2>, opaque = 0x55748acf8c90, aio_context = 0x55748acd1080, + aio_notifiers = {lh_first = 0x0}, walking_aio_notifiers = false, filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing_file = '\000' <repeats 4095 times>, auto_backing_file = '\000' <repeats 4095 times>, + backing_format = '\000' <repeats 15 times>, full_open_options = 0x55748b3c68e0, exact_filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing = 0x0, file = 0x55748aa5de40, bl = {request_alignment = 1, + max_pdiscard = 0, pdiscard_alignment = 65536, max_pwrite_zeroes = 0, pwrite_zeroes_alignment = 65536, opt_transfer = 0, max_transfer = 0, min_mem_alignment = 512, opt_mem_alignment = 4096, max_iov = 1024}, supported_write_flags = 0, + supported_zero_flags = 260, supported_truncate_flags = 2, node_name = "libvirt-2-format", '\000' <repeats 15 times>, node_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0e8}}, + bs_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0f8}}, monitor_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d108}}, refcnt = 2, + op_blockers = {{lh_first = 0x0} <repeats 16 times>}, inherits_from = 0x0, children = {lh_first = 0x55748aa5de40}, parents = {lh_first = 0x55748bbc0380}, options = 0x55748ad4d2d0, explicit_options = 0x55748ad525a0, + detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, backing_blocker = 0x0, total_sectors = 4194304, 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 = 0x55748b4655f0}, wr_highest_offset = {value = 0}, copy_on_read = 0, in_flight = 0, serialising_in_flight = 0, io_plugged = 0, + enable_write_cache = 0, quiesce_counter = 0, recursive_quiesce_counter = 0, write_gen = 0, 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 = 0x55748ad52570}}, active_flush_req = false, flushed_gen = 0, never_freeze = false} +``` + +When we merge into commit https://gitlab.com/qemu-project/qemu/-/commit/31e4c354b38cd42a051ad030eb7779d5e7ee32fe and then run `block-bitmap-mapping` before migration, the hot migration can be completed successfully. I would like to confirm with the community whether this solution is reasonable and if there are any other solutions to address this issue. + +``` +virsh qemu-monitor-command i-btacsctt '{"execute": "migrate-set-parameters", "arguments":{"block-bitmap-mapping":[{"node-name":"libvirt-2-format", "alias":"libvirt-3-format","bitmaps":[{"name":"bitmap0", "alias":"bitmap0"}]}]}}' +``` diff --git a/results/classifier/zero-shot/108/none/2651 b/results/classifier/zero-shot/108/none/2651 new file mode 100644 index 000000000..ab904161c --- /dev/null +++ b/results/classifier/zero-shot/108/none/2651 @@ -0,0 +1,23 @@ +device: 0.599 +graphic: 0.468 +network: 0.328 +vnc: 0.307 +other: 0.300 +socket: 0.247 +semantic: 0.180 +boot: 0.153 +PID: 0.105 +files: 0.086 +performance: 0.084 +KVM: 0.073 +debug: 0.016 +permissions: 0.010 + +MPC5553/MPC5554 Emulation (information request) +Additional information: +If it is not planned, I'll most likely start educating myself on this project to try and patch it in as it's a need that is quite important for me. +I'll try not to waste your time and read as much as I can about your guidelines. +Would you advise me against trying to do this? +I'd like to know how hard you think this will be. + +DISCLAIMER : I am still very much a newbie in embedded systems, I'm only in the first year of my master's degree in embedded systems. diff --git a/results/classifier/zero-shot/108/none/2677 b/results/classifier/zero-shot/108/none/2677 new file mode 100644 index 000000000..f65c90332 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2677 @@ -0,0 +1,16 @@ +device: 0.272 +files: 0.269 +KVM: 0.229 +PID: 0.221 +vnc: 0.207 +boot: 0.197 +semantic: 0.166 +network: 0.138 +permissions: 0.134 +graphic: 0.113 +performance: 0.102 +other: 0.087 +socket: 0.071 +debug: 0.059 + +edit doc on building diff --git a/results/classifier/zero-shot/108/none/2684 b/results/classifier/zero-shot/108/none/2684 new file mode 100644 index 000000000..6e6020f40 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2684 @@ -0,0 +1,16 @@ +other: 0.405 +device: 0.332 +semantic: 0.302 +graphic: 0.189 +permissions: 0.156 +performance: 0.140 +files: 0.127 +PID: 0.119 +vnc: 0.104 +network: 0.086 +KVM: 0.065 +socket: 0.044 +boot: 0.035 +debug: 0.021 + +scripts/archive-source.sh is not documented diff --git a/results/classifier/zero-shot/108/none/2709 b/results/classifier/zero-shot/108/none/2709 new file mode 100644 index 000000000..95da2fbc6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2709 @@ -0,0 +1,16 @@ +other: 0.508 +semantic: 0.456 +device: 0.382 +socket: 0.362 +permissions: 0.295 +boot: 0.261 +files: 0.244 +PID: 0.227 +KVM: 0.189 +vnc: 0.157 +network: 0.105 +graphic: 0.066 +debug: 0.052 +performance: 0.026 + +Contributing to docs is very confusing diff --git a/results/classifier/zero-shot/108/none/2737 b/results/classifier/zero-shot/108/none/2737 new file mode 100644 index 000000000..49a6b0b84 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2737 @@ -0,0 +1,16 @@ +device: 0.545 +network: 0.336 +graphic: 0.255 +performance: 0.251 +semantic: 0.249 +boot: 0.227 +vnc: 0.223 +files: 0.223 +socket: 0.193 +other: 0.182 +permissions: 0.146 +debug: 0.133 +PID: 0.078 +KVM: 0.037 + +Plans for Adding RISC-V Vector (RVV) Backend Support? diff --git a/results/classifier/zero-shot/108/none/2740 b/results/classifier/zero-shot/108/none/2740 new file mode 100644 index 000000000..7aaa90f07 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2740 @@ -0,0 +1,82 @@ +other: 0.590 +vnc: 0.589 +debug: 0.553 +network: 0.547 +device: 0.542 +KVM: 0.542 +permissions: 0.527 +PID: 0.517 +graphic: 0.515 +boot: 0.514 +performance: 0.513 +semantic: 0.509 +socket: 0.460 +files: 0.437 + +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/zero-shot/108/none/2753 b/results/classifier/zero-shot/108/none/2753 new file mode 100644 index 000000000..4daf8a50c --- /dev/null +++ b/results/classifier/zero-shot/108/none/2753 @@ -0,0 +1,139 @@ +other: 0.493 +permissions: 0.447 +graphic: 0.444 +files: 0.436 +socket: 0.412 +network: 0.406 +semantic: 0.405 +performance: 0.390 +device: 0.386 +PID: 0.374 +debug: 0.340 +vnc: 0.334 +KVM: 0.295 +boot: 0.237 + +Uninitialized read in vhost_user_backend_init. +Description of problem: +In backends/cryptodev-vhost.c::cryptodev_vhost_init, crypto->dev.config_ops is not initialized (See code below). I think here `g_new0` should be used instead of `g_new`. +``` +struct CryptoDevBackendVhost * +cryptodev_vhost_init( + CryptoDevBackendVhostOptions *options) +{ + ... + crypto = g_new(CryptoDevBackendVhost, 1); + crypto->dev.max_queues = 1; + crypto->dev.nvqs = 1; + crypto->dev.vqs = crypto->vqs; + + crypto->cc = options->cc; + + crypto->dev.protocol_features = 0; + crypto->backend = -1; + ... +} +``` +In vhost_user_backend_init, crypto->dev.config_ops will be dereferenced. Since it is uninitialized with 0, it is possible that a random value pointer will be dereferenced. +``` +static int vhost_user_backend_init(struct vhost_dev *dev, void *opaque, + Error **errp) +{ + ... + if (virtio_has_feature(features, VHOST_USER_F_PROTOCOL_FEATURES)) { + bool supports_f_config = vus->supports_config || + (dev->config_ops && dev->config_ops->vhost_dev_config_notifier); + uint64_t protocol_features; + ... +``` + + +As a result, ASAN will capture this uninitialized, since it assigns 0xbe to every bytes of allocated but uninitilized memory. +Steps to reproduce: +1.Build dpdk vhost-user crypto backend. Following instructions here: [DPDK installation](https://doc.dpdk.org/guides/prog_guide/build-sdk-meson.html) +``` +wget https://fast.dpdk.org/rel/dpdk-24.11.tar.xz +meson setup -Dexamples=all build +cd build +ninja +meson install +cd examples +sudo ./dpdk-vhost_crypto --vdev 'crypto_aesni_mb0' -- --config \(7,0,0\) --socket-file=7,/tmp/my-crypto.sock +``` +After setting up the backend, should see something like: +``` +EAL: Detected CPU lcores: 48 +EAL: Detected NUMA nodes: 2 +EAL: Detected static linkage of DPDK +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: Selected IOVA mode 'PA' +EAL: VFIO support initialized +CRYPTODEV: Creating cryptodev crypto_aesni_mb0 +CRYPTODEV: Initialisation parameters - name: crypto_aesni_mb0,socket id: 0, max queue pairs: 8 +IPSEC_MB: ipsec_mb_create() line 168: IPSec Multi-buffer library version used: 2.0.0 +USER1: Processing on Core 7 started +VHOST_CONFIG: (/tmp/my-crypto.sock) logging feature is disabled in async copy mode +VHOST_CONFIG: (/tmp/my-crypto.sock) vhost-user server: socket created, fd: 213 +VHOST_CONFIG: (/tmp/my-crypto.sock) binding succeeded +``` + +2.Build qemu with ASAN (i.e., --enable-asan) and vhost support (i.e., --enable-vhost-user --enable-vhost-crypto) + +3.Ensure that /dev/hugemaps and /tmp/my-crypto.sock can be accessed. You may need to change their permissions by chmod, or run qemu-system as root. + +4.Run the command below to reproduce problem. +``` +cat << EOF | \ +./qemu-system-x86_64 --enable-kvm -m 512M \ +-object \ +memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on \ +-numa node,memdev=mem -smp cpus=4 -machine q35 -chardev \ +socket,id=chardev0,path=/tmp/my-crypto.sock -object \ +cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 -device \ +virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -display none -qtest \ +stdio +EOF +``` +Additional information: +Here is the information reported by ASAN: +``` +==2270320==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 0.000000] OPENED +../hw/virtio/vhost-user.c:2183:50: runtime error: member access within misaligned address 0xbebebebebebebebe for type 'const VhostDevConfigOps' (aka 'const struct VhostDevConfigOps'), which requires 8 byte alignment +0xbebebebebebebebe: note: pointer points here +<memory cannot be printed> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/virtio/vhost-user.c:2183:50 in +../hw/virtio/vhost-user.c:2183:50: runtime error: load of misaligned address 0xbebebebebebebebe for type 'int (*const)(struct vhost_dev *)', which requires 8 byte alignment +0xbebebebebebebebe: note: pointer points here +<memory cannot be printed> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/virtio/vhost-user.c:2183:50 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==2270320==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x5619d01bd606 bp 0x7fffc6d3add0 sp 0x7fffc6d3a4e0 T0) +==2270320==The signal is caused by a READ memory access. +==2270320==Hint: this fault was caused by a dereference of a high value address (see register values below). Disassemble the provided pc to learn which register was used. + #0 0x5619d01bd606 in vhost_user_backend_init /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:2183:50 + #1 0x5619ced13a08 in vhost_dev_init /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1523:9 + #2 0x5619cef8cc30 in cryptodev_vhost_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:69:9 + #3 0x5619cef9aca6 in cryptodev_vhost_user_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:108:30 + #4 0x5619cef9a599 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:164:13 + #5 0x5619d0e22ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5 + #6 0x5619d0e18465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5 + #7 0x5619d0de5d42 in qemu_chr_fe_set_handlers_full /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:283:13 + #8 0x5619d0de5674 in qemu_chr_fe_set_handlers /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:297:5 + #9 0x5619cef98960 in cryptodev_vhost_user_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:220:5 + #10 0x5619cef71e98 in cryptodev_backend_complete /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev.c:420:9 + #11 0x5619d067dc40 in user_creatable_complete /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:28:9 + #12 0x5619d067e6a8 in user_creatable_add_type /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:125:10 + #13 0x5619d067ec74 in user_creatable_add_qapi /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:157:11 + #14 0x5619cef5582b in object_option_foreach_add /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:1809:13 + #15 0x5619cef5253c in qemu_create_late_backends /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:2029:5 + #16 0x5619cef46efe in qemu_init /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:3726:5 + #17 0x5619d0e46f11 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:47:5 + #18 0x7efeef09a082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16 + #19 0x5619cd0be89d in _start (/mnt/Hypervisor/qemu/build/master/fuzz/qemu-system-x86_64+0x2c8b89d) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:2183:50 in vhost_user_backend_init +==2270320==ABORTING +``` diff --git a/results/classifier/zero-shot/108/none/2769 b/results/classifier/zero-shot/108/none/2769 new file mode 100644 index 000000000..2a9de67e8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2769 @@ -0,0 +1,18 @@ +device: 0.587 +network: 0.388 +semantic: 0.365 +boot: 0.207 +socket: 0.166 +KVM: 0.160 +performance: 0.148 +graphic: 0.139 +debug: 0.098 +vnc: 0.092 +other: 0.087 +PID: 0.062 +permissions: 0.015 +files: 0.009 + +Ability to set smbios type 3 field "Type" +Additional information: +That's all :) diff --git a/results/classifier/zero-shot/108/none/2771 b/results/classifier/zero-shot/108/none/2771 new file mode 100644 index 000000000..22ad017c4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2771 @@ -0,0 +1,16 @@ +device: 0.564 +performance: 0.493 +debug: 0.428 +graphic: 0.401 +PID: 0.316 +files: 0.245 +semantic: 0.243 +vnc: 0.228 +network: 0.211 +permissions: 0.179 +socket: 0.160 +boot: 0.124 +KVM: 0.063 +other: 0.036 + +qemu-system-x86_64: ../block/block-backend.c:1290: blk_in_drain: Assertion `qemu_in_main_thread()' failed. diff --git a/results/classifier/zero-shot/108/none/2774 b/results/classifier/zero-shot/108/none/2774 new file mode 100644 index 000000000..bf57c83dd --- /dev/null +++ b/results/classifier/zero-shot/108/none/2774 @@ -0,0 +1,18 @@ +graphic: 0.440 +boot: 0.348 +device: 0.295 +semantic: 0.286 +vnc: 0.223 +other: 0.180 +debug: 0.074 +performance: 0.050 +socket: 0.032 +files: 0.026 +permissions: 0.020 +network: 0.020 +PID: 0.016 +KVM: 0.002 + +Consider adding an `aliases` node to RISC-V DTB that includes `serial0` alias +Additional information: +Example of an [aliases section for physical SoC](https://github.com/torvalds/linux/blob/b62cef9a5c673f1b8083159f5dc03c1c5daced2f/arch/riscv/boot/dts/sophgo/cv1800b-milkv-duo.dts#L14-L20). diff --git a/results/classifier/zero-shot/108/none/2781 b/results/classifier/zero-shot/108/none/2781 new file mode 100644 index 000000000..31467bae3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2781 @@ -0,0 +1,16 @@ +files: 0.570 +device: 0.567 +performance: 0.449 +network: 0.389 +PID: 0.356 +graphic: 0.316 +permissions: 0.314 +other: 0.254 +boot: 0.252 +KVM: 0.238 +vnc: 0.219 +semantic: 0.185 +debug: 0.168 +socket: 0.035 + +Open logfiles for append diff --git a/results/classifier/zero-shot/108/none/2795 b/results/classifier/zero-shot/108/none/2795 new file mode 100644 index 000000000..9b34d13b3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2795 @@ -0,0 +1,175 @@ +other: 0.564 +graphic: 0.560 +vnc: 0.548 +permissions: 0.546 +boot: 0.541 +device: 0.523 +network: 0.519 +performance: 0.519 +KVM: 0.516 +debug: 0.507 +socket: 0.499 +semantic: 0.496 +PID: 0.481 +files: 0.438 + +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/zero-shot/108/none/2808 b/results/classifier/zero-shot/108/none/2808 new file mode 100644 index 000000000..739d63f8e --- /dev/null +++ b/results/classifier/zero-shot/108/none/2808 @@ -0,0 +1,16 @@ +device: 0.526 +other: 0.390 +network: 0.321 +semantic: 0.304 +socket: 0.299 +boot: 0.243 +graphic: 0.233 +permissions: 0.214 +performance: 0.194 +PID: 0.165 +debug: 0.152 +files: 0.144 +vnc: 0.137 +KVM: 0.026 + +Links to the RISC-V IOMMU Architecture Specification are broken in the docs diff --git a/results/classifier/zero-shot/108/none/2855 b/results/classifier/zero-shot/108/none/2855 new file mode 100644 index 000000000..ffd1c3104 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2855 @@ -0,0 +1,44 @@ +device: 0.456 +performance: 0.374 +permissions: 0.337 +graphic: 0.315 +other: 0.291 +network: 0.239 +PID: 0.216 +socket: 0.212 +semantic: 0.204 +boot: 0.160 +vnc: 0.158 +files: 0.151 +debug: 0.146 +KVM: 0.121 + +masking mode field in mepc before mret +Description of problem: +I thought I found a bug in OpenSBI (https://github.com/riscv-software-src/opensbi/issues/391) but it actually is a QEMU bug. +It is described here: https://lists.infradead.org/pipermail/opensbi/2025-March/008166.html +Steps to reproduce: +1. use an application with vectored mode enabled (The RISC-V Instruction Set Manual: Volume II: Privileged Architecture / chapter 10.1.2) in QEMU +2. trigger an illegal instruction interrupt (handle it in machine mode - not by medeleg) +3. in a machine mode trap: Store STVEC in MEPC. +4. do a mret +5. the first bits of mepc are not masked so the address in mepc (comming from (v)stvec) will be false after mret +Additional information: +My guess is that the instructions from the following quote (masking of lower bits in mepc) from the official spec must be implemented here: +https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/op_helper.c?ref_type=heads#L387 +Maybe also somewhere else. + +> 3.1.14. Machine Exception Program Counter (mepc) +> +> mepc is an MXLEN-bit read/write register formatted as shown in Figure 21. The low bit of mepc +> (mepc[0]) is always zero. On implementations that support only IALIGN=32, the two low bits +> (mepc[1:0]) are always zero. +> +> If an implementation allows IALIGN to be either 16 or 32 (by changing CSR misa, for example), then, +> whenever IALIGN=32, bit mepc[1] is masked on reads so that it appears to be 0. This masking occurs +> also for the implicit read by the MRET instruction. Though masked, mepc[1] remains writable when +> IALIGN=32. +> +> mepc is a WARL register that must be able to hold all valid virtual addresses. It need not be capable of +> holding all possible invalid addresses. Prior to writing mepc, implementations may convert an invalid +> address into some other invalid address that mepc is capable of holding. diff --git a/results/classifier/zero-shot/108/none/2901 b/results/classifier/zero-shot/108/none/2901 new file mode 100644 index 000000000..5c09933ce --- /dev/null +++ b/results/classifier/zero-shot/108/none/2901 @@ -0,0 +1,16 @@ +device: 0.597 +graphic: 0.420 +network: 0.360 +performance: 0.290 +vnc: 0.282 +permissions: 0.254 +socket: 0.253 +boot: 0.227 +PID: 0.203 +other: 0.191 +semantic: 0.175 +files: 0.172 +debug: 0.075 +KVM: 0.037 + +Critical typo in qemu_source_dir/plugins/loader.c diff --git a/results/classifier/zero-shot/108/none/2950 b/results/classifier/zero-shot/108/none/2950 new file mode 100644 index 000000000..cad9309f7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2950 @@ -0,0 +1,80 @@ +KVM: 0.542 +other: 0.461 +device: 0.454 +vnc: 0.454 +performance: 0.438 +boot: 0.434 +permissions: 0.430 +semantic: 0.427 +graphic: 0.423 +network: 0.421 +debug: 0.419 +files: 0.407 +PID: 0.402 +socket: 0.396 + +QEMU 10 breaks Incus' NVME handling +Description of problem: +Incus is an open-source container and VM manager. +For VMs we naturally use QEMU where we basically: + - Use QMP as much as possible to put together the VM prior to starting emulation + - Put the static pre-start stuff in a config file + use readconfig + - Keep the command line to a bare minimum + +This isn't particularly relevant to this issue except for the first point which is our use of QMP for most device handling. That means qemu is spawned without any disk or network attached. We have a `virtio-scsi` controller in the base config file but that's it. + +When doing NVME, we hotplug a new drive and a new nvme device pointing to that drive. +This means that our setup has a 1:1 mapping between NVME controllers on the PCIe bus and drives. + +This worked great up until QEMU 10. With QEMU 10, I believe this commit https://gitlab.com/qemu-project/qemu/-/commit/cd59f50ab017183805a0dd82f5e85159ecc355ce by @birkelund now effectively causes the creation of a `nvme-subsys` device when we add a `nvme` device without a pre-existing subsystem. + +As `nvme-subsys` doesn't support hotplugging, this immediately breaks all our VMs that rely on NVME. + +``` +stgraber@dakara:~$ incus start test-nvme +Error: Failed setting up device via monitor: Failed adding block device for disk device "root": Failed adding device: Device 'nvme-subsys' does not support hotplugging +Try `incus info --show-log test-nvme` for more info +``` + +As you can see, QEMU returns `Device 'nvme-subsys' does not support hotplugging`. + +On the QMP front, we did: +``` +stgraber@dakara:~$ sudo cat /var/log/incus/test-nvme/qemu.qmp.log +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"qom-get","arguments":{"path":"/machine","property":"type"}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": "pc-q35-10.0-machine"} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"query-cpus-fast"} +[2025-05-06T11:42:30-04:00] REPLY: {"return": [{"thread-id": 3885061, "props": {"core-id": 0, "thread-id": 0, "node-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}]} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"netdev_add","arguments":{"fds":"/dev/net/tun.0:/dev/net/tun.1","id":"incus_eth0","type":"tap","vhost":true,"vhostfds":"/dev/vhost-net.0:/dev/vhost-net.1"}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"device_add","arguments":{"addr":"00.0","bootindex":1,"bus":"qemu_pcie4","driver":"virtio-net-pci","id":"dev-incus_eth0","mac":"10:66:6a:30:97:66","mq":true,"netdev":"incus_eth0","vectors":6}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"blockdev-add","arguments":{"aio":"native","cache":{"direct":true,"no-flush":false},"discard":"unmap","driver":"host_device","filename":"/dev/fdset/0","locking":"off","node-name":"incus_root","read-only":false}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"device_add","arguments":{"addr":"00.0","bootindex":0,"bus":"qemu_pcie5","drive":"incus_root","driver":"nvme","id":"dev-incus_root","serial":"incus_root"}} +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"blockdev-del","arguments":{"node-name":"incus_root"}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"query-fdsets"} +[2025-05-06T11:42:30-04:00] REPLY: {"return": [{"fds": [{"fd": 49, "opaque": "rdwr:incus_root"}], "fdset-id": 0}]} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"remove-fd","arguments":{"fdset-id":0}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} +``` +Additional information: +My limited understanding of NVME concepts is that NVME controllers are tied to a subsystem, then drives are tied to namespaces which themselves are tied to subsystems. + +So in a world where we need to deal with QEMU not supporting hotplugging subsystems, we would be able to create a single subsystem with a single controller and then hot plug/remove drives+namespaces into that. + +I've not actually tested this because to us it's not really an option. +We have users that for better or for worse currently rely on the current behavior of having each drive have its own controller, and so on the Linux side expect to see one PCIe device per drive and then one `/dev/nvmeXn1` device per drive. + +Changing this to be multiple namespaces on controller 0 would break anyone who ever hardcoded /dev/nvmeXn1 on their system and may also lead to different performance characteristics due to now using a single controller. Multiple controllers would still be an option of course, but they'd be tied to the same subsystem and namespaces so effectively now having the guest do NVME multipath. + + +Anyway, let me know if I'm missing a way to get QEMU 10 to behave as we did in releases prior, where I can start a VM with 0 NVME controllers, then add a couple of drives, each showing up as their own controller with the drive as namespace 1 on that. diff --git a/results/classifier/zero-shot/108/none/2984 b/results/classifier/zero-shot/108/none/2984 new file mode 100644 index 000000000..20580e452 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2984 @@ -0,0 +1,68 @@ +PID: 0.407 +boot: 0.357 +performance: 0.350 +device: 0.335 +vnc: 0.327 +semantic: 0.298 +permissions: 0.276 +debug: 0.270 +network: 0.267 +other: 0.255 +graphic: 0.242 +KVM: 0.223 +socket: 0.207 +files: 0.160 + +CPU hotplug crashed the guest when using virt-type as qemu! +Description of problem: +Guest is getting crashing and getting into shutoff state when I am trying to hotplug much more cpus than present in the host! This is happening only when i give virt-type as qemu. +Additional information: +Tried reproducing while attaching gdb shows below backtrace which happened after hotplugging 249 CPUs in TCG mode: + +``` +Thread 261 "CPU 249/TCG" received signal SIGABRT, Aborted. +[Switching to Thread 0x7ff97c00ea20 (LWP 51567)] +0x00007fff84cac3e8 in __pthread_kill_implementation () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +(gdb) bt +#0 0x00007fff84cac3e8 in __pthread_kill_implementation () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#1 0x00007fff84c46ba0 in raise () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#2 0x00007fff84c29354 in abort () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#3 0x00007fff850f1e30 in g_assertion_message () from target:/lib64/libglib-2.0.so.0 +#4 0x00007fff850f1ebc in g_assertion_message_expr () from target:/lib64/libglib-2.0.so.0 +#5 0x00000001376c6f00 in tcg_region_initial_alloc__locked (s=0x7fff7c000f30) at ../tcg/region.c:396 +#6 0x00000001376c6fa8 in tcg_region_initial_alloc (s=0x7fff7c000f30) at ../tcg/region.c:402 +#7 0x00000001376dae08 in tcg_register_thread () at ../tcg/tcg.c:1011 +#8 0x000000013768b7e4 in mttcg_cpu_thread_fn (arg=0x143e884f0) at ../accel/tcg/tcg-accel-ops-mttcg.c:77 +#9 0x0000000137bbb2d0 in qemu_thread_start (args=0x143b4aff0) at ../util/qemu-thread-posix.c:542 +#10 0x00007fff84ca9be0 in start_thread () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#11 0x00007fff84d4ef3c in __clone3 () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +(gdb) +``` + +which points to below code: + +``` +/* + * Perform a context's first region allocation. + * This function does _not_ increment region.agg_size_full. + */ +static void tcg_region_initial_alloc__locked(TCGContext *s) +{ + bool err = tcg_region_alloc__locked(s); + g_assert(!err); +} +``` + +Here, tcg_region_alloc__locked returns true on failure when max region allocation is reached and therefore intentionally asserted as TCG can't proceed without it. + +``` +static bool tcg_region_alloc__locked(TCGContext *s) +{ + if (region.current == region.n) { + return true; + } + tcg_region_assign(s, region.current); + region.current++; + return false; +} +``` diff --git a/results/classifier/zero-shot/108/none/2988 b/results/classifier/zero-shot/108/none/2988 new file mode 100644 index 000000000..9e7d477f3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/2988 @@ -0,0 +1,22 @@ +graphic: 0.339 +semantic: 0.216 +device: 0.088 +other: 0.024 +socket: 0.009 +debug: 0.009 +PID: 0.008 +performance: 0.007 +vnc: 0.006 +boot: 0.005 +files: 0.004 +network: 0.003 +permissions: 0.003 +KVM: 0.001 + +Absolute mouse mode is broken in SDL2 +Description of problem: +Absolute mouse mode is broken in SDL2. Bisected at 30aa105640b0a2a541744b6584d57c9a4b86debd. + +Relative mouse mode has never worked in stretched SDL2 Display for display controllers that passed through cursor data and have positions warped by HOST UI backend. It looks like 30aa105640b0a2a541744b6584d57c9a4b86debd tried to fix this but it didn't work out. Scaling **"relative motions"** isn't straight-forward as what the commit had expected. + +Absolute mouse mode mode has always worked in stretched SDL2 Display. 30aa105640b0a2a541744b6584d57c9a4b86debd broke it without fixing anything. diff --git a/results/classifier/zero-shot/108/none/327 b/results/classifier/zero-shot/108/none/327 new file mode 100644 index 000000000..9277019ec --- /dev/null +++ b/results/classifier/zero-shot/108/none/327 @@ -0,0 +1,16 @@ +files: 0.487 +vnc: 0.368 +PID: 0.335 +graphic: 0.320 +device: 0.281 +boot: 0.280 +performance: 0.250 +KVM: 0.149 +debug: 0.058 +semantic: 0.055 +other: 0.054 +permissions: 0.015 +socket: 0.005 +network: 0.001 + +Storage | Two decimal digits precision diff --git a/results/classifier/zero-shot/108/none/353 b/results/classifier/zero-shot/108/none/353 new file mode 100644 index 000000000..e1dac97c8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/353 @@ -0,0 +1,16 @@ +device: 0.598 +vnc: 0.547 +boot: 0.328 +KVM: 0.265 +graphic: 0.245 +PID: 0.226 +permissions: 0.167 +other: 0.156 +debug: 0.115 +performance: 0.107 +network: 0.074 +socket: 0.037 +semantic: 0.036 +files: 0.005 + +video capture, slowness diff --git a/results/classifier/zero-shot/108/none/361 b/results/classifier/zero-shot/108/none/361 new file mode 100644 index 000000000..73ce00eb9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/361 @@ -0,0 +1,16 @@ +semantic: 0.465 +graphic: 0.432 +performance: 0.350 +debug: 0.305 +vnc: 0.253 +device: 0.243 +boot: 0.163 +PID: 0.141 +KVM: 0.134 +other: 0.106 +permissions: 0.092 +network: 0.006 +socket: 0.006 +files: 0.002 + +-cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/zero-shot/108/none/369 b/results/classifier/zero-shot/108/none/369 new file mode 100644 index 000000000..5655594ff --- /dev/null +++ b/results/classifier/zero-shot/108/none/369 @@ -0,0 +1,16 @@ +semantic: 0.420 +other: 0.270 +graphic: 0.176 +KVM: 0.159 +vnc: 0.127 +PID: 0.112 +boot: 0.099 +socket: 0.097 +device: 0.085 +network: 0.054 +performance: 0.054 +files: 0.044 +permissions: 0.028 +debug: 0.021 + +Remove leading underscores from #defines diff --git a/results/classifier/zero-shot/108/none/371 b/results/classifier/zero-shot/108/none/371 new file mode 100644 index 000000000..353e26dd4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/371 @@ -0,0 +1,16 @@ +graphic: 0.454 +device: 0.449 +other: 0.438 +socket: 0.409 +semantic: 0.331 +performance: 0.296 +PID: 0.280 +debug: 0.266 +boot: 0.263 +vnc: 0.258 +KVM: 0.228 +network: 0.213 +files: 0.192 +permissions: 0.190 + +Indentation should be done with spaces, not with TABs, in the block subsystem diff --git a/results/classifier/zero-shot/108/none/382 b/results/classifier/zero-shot/108/none/382 new file mode 100644 index 000000000..21e59aa0e --- /dev/null +++ b/results/classifier/zero-shot/108/none/382 @@ -0,0 +1,16 @@ +semantic: 0.527 +files: 0.453 +graphic: 0.376 +device: 0.331 +debug: 0.204 +performance: 0.129 +socket: 0.115 +boot: 0.085 +vnc: 0.075 +network: 0.069 +other: 0.034 +PID: 0.034 +permissions: 0.027 +KVM: 0.017 + +target/i386/seg_helper.c: 16-bit TSS struct format wrong? diff --git a/results/classifier/zero-shot/108/none/395 b/results/classifier/zero-shot/108/none/395 new file mode 100644 index 000000000..7996a5a1b --- /dev/null +++ b/results/classifier/zero-shot/108/none/395 @@ -0,0 +1,16 @@ +device: 0.398 +PID: 0.282 +boot: 0.230 +network: 0.190 +permissions: 0.189 +performance: 0.160 +semantic: 0.159 +socket: 0.156 +graphic: 0.145 +other: 0.080 +files: 0.046 +debug: 0.034 +KVM: 0.032 +vnc: 0.024 + +Write a python style guide document diff --git a/results/classifier/zero-shot/108/none/397 b/results/classifier/zero-shot/108/none/397 new file mode 100644 index 000000000..a183361a8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/397 @@ -0,0 +1,16 @@ +device: 0.596 +performance: 0.583 +permissions: 0.496 +other: 0.441 +graphic: 0.390 +semantic: 0.252 +debug: 0.158 +network: 0.049 +files: 0.045 +PID: 0.030 +socket: 0.029 +vnc: 0.025 +boot: 0.022 +KVM: 0.005 + +Cannot run qemu at all diff --git a/results/classifier/zero-shot/108/none/400 b/results/classifier/zero-shot/108/none/400 new file mode 100644 index 000000000..5d8614894 --- /dev/null +++ b/results/classifier/zero-shot/108/none/400 @@ -0,0 +1,16 @@ +device: 0.482 +graphic: 0.325 +performance: 0.255 +debug: 0.250 +vnc: 0.193 +semantic: 0.187 +network: 0.160 +PID: 0.142 +files: 0.078 +permissions: 0.073 +socket: 0.065 +other: 0.063 +boot: 0.059 +KVM: 0.011 + +Build error -Werror=stringop-overflow in util/qemu-thread-posix.c diff --git a/results/classifier/zero-shot/108/none/419 b/results/classifier/zero-shot/108/none/419 new file mode 100644 index 000000000..080c36865 --- /dev/null +++ b/results/classifier/zero-shot/108/none/419 @@ -0,0 +1,16 @@ +debug: 0.385 +device: 0.378 +network: 0.345 +performance: 0.285 +graphic: 0.230 +PID: 0.203 +semantic: 0.144 +boot: 0.133 +permissions: 0.098 +vnc: 0.070 +socket: 0.048 +files: 0.042 +KVM: 0.017 +other: 0.006 + +bsd-user dumps core for all binaries emulated diff --git a/results/classifier/zero-shot/108/none/42613410 b/results/classifier/zero-shot/108/none/42613410 new file mode 100644 index 000000000..4d3ce0dfe --- /dev/null +++ b/results/classifier/zero-shot/108/none/42613410 @@ -0,0 +1,159 @@ +vnc: 0.400 +KVM: 0.381 +permissions: 0.373 +device: 0.342 +other: 0.332 +graphic: 0.330 +semantic: 0.327 +performance: 0.324 +debug: 0.311 +network: 0.284 +PID: 0.276 +files: 0.264 +socket: 0.190 +boot: 0.187 + +[Qemu-devel] [PATCH, Bug 1612908] scripts: Add TCP endpoints for qom-* scripts + +From: Carl Allendorph <address@hidden> + +I've created a patch for bug #1612908. The current docs for the scripts +in the "scripts/qmp/" directory suggest that both unix sockets and +tcp endpoints can be used. The TCP endpoints don't work for most of the +scripts, with notable exception of 'qmp-shell'. This patch attempts to +refactor the process of distinguishing between unix path endpoints and +tcp endpoints to work for all of these scripts. + +Carl Allendorph (1): + scripts: Add ability for qom-* python scripts to target tcp endpoints + + scripts/qmp/qmp-shell | 22 ++-------------------- + scripts/qmp/qmp.py | 23 ++++++++++++++++++++--- + 2 files changed, 22 insertions(+), 23 deletions(-) + +-- +2.7.4 + +From: Carl Allendorph <address@hidden> + +The current code for QEMUMonitorProtocol accepts both a unix socket +endpoint as a string and a tcp endpoint as a tuple. Most of the scripts +that use this class don't massage the command line argument to generate +a tuple. This patch refactors qmp-shell slightly to reuse the existing +parsing of the "host:port" string for all the qom-* scripts. + +Signed-off-by: Carl Allendorph <address@hidden> +--- + scripts/qmp/qmp-shell | 22 ++-------------------- + scripts/qmp/qmp.py | 23 ++++++++++++++++++++--- + 2 files changed, 22 insertions(+), 23 deletions(-) + +diff --git a/scripts/qmp/qmp-shell b/scripts/qmp/qmp-shell +index 0373b24..8a2a437 100755 +--- a/scripts/qmp/qmp-shell ++++ b/scripts/qmp/qmp-shell +@@ -83,9 +83,6 @@ class QMPCompleter(list): + class QMPShellError(Exception): + pass + +-class QMPShellBadPort(QMPShellError): +- pass +- + class FuzzyJSON(ast.NodeTransformer): + '''This extension of ast.NodeTransformer filters literal "true/false/null" + values in an AST and replaces them by proper "True/False/None" values that +@@ -103,28 +100,13 @@ class FuzzyJSON(ast.NodeTransformer): + # _execute_cmd()). Let's design a better one. + class QMPShell(qmp.QEMUMonitorProtocol): + def __init__(self, address, pretty=False): +- qmp.QEMUMonitorProtocol.__init__(self, self.__get_address(address)) ++ qmp.QEMUMonitorProtocol.__init__(self, address) + self._greeting = None + self._completer = None + self._pretty = pretty + self._transmode = False + self._actions = list() + +- def __get_address(self, arg): +- """ +- Figure out if the argument is in the port:host form, if it's not it's +- probably a file path. +- """ +- addr = arg.split(':') +- if len(addr) == 2: +- try: +- port = int(addr[1]) +- except ValueError: +- raise QMPShellBadPort +- return ( addr[0], port ) +- # socket path +- return arg +- + def _fill_completion(self): + for cmd in self.cmd('query-commands')['return']: + self._completer.append(cmd['name']) +@@ -400,7 +382,7 @@ def main(): + + if qemu is None: + fail_cmdline() +- except QMPShellBadPort: ++ except qmp.QMPShellBadPort: + die('bad port number in command-line') + + try: +diff --git a/scripts/qmp/qmp.py b/scripts/qmp/qmp.py +index 62d3651..261ece8 100644 +--- a/scripts/qmp/qmp.py ++++ b/scripts/qmp/qmp.py +@@ -25,21 +25,23 @@ class QMPCapabilitiesError(QMPError): + class QMPTimeoutError(QMPError): + pass + ++class QMPShellBadPort(QMPError): ++ pass ++ + class QEMUMonitorProtocol: + def __init__(self, address, server=False, debug=False): + """ + Create a QEMUMonitorProtocol class. + + @param address: QEMU address, can be either a unix socket path (string) +- or a tuple in the form ( address, port ) for a TCP +- connection ++ or a TCP endpoint (string in the format "host:port") + @param server: server mode listens on the socket (bool) + @raise socket.error on socket connection errors + @note No connection is established, this is done by the connect() or + accept() methods + """ + self.__events = [] +- self.__address = address ++ self.__address = self.__get_address(address) + self._debug = debug + self.__sock = self.__get_sock() + if server: +@@ -47,6 +49,21 @@ class QEMUMonitorProtocol: + self.__sock.bind(self.__address) + self.__sock.listen(1) + ++ def __get_address(self, arg): ++ """ ++ Figure out if the argument is in the port:host form, if it's not it's ++ probably a file path. ++ """ ++ addr = arg.split(':') ++ if len(addr) == 2: ++ try: ++ port = int(addr[1]) ++ except ValueError: ++ raise QMPShellBadPort ++ return ( addr[0], port ) ++ # socket path ++ return arg ++ + def __get_sock(self): + if isinstance(self.__address, tuple): + family = socket.AF_INET +-- +2.7.4 + diff --git a/results/classifier/zero-shot/108/none/440 b/results/classifier/zero-shot/108/none/440 new file mode 100644 index 000000000..8a2e852f1 --- /dev/null +++ b/results/classifier/zero-shot/108/none/440 @@ -0,0 +1,16 @@ +performance: 0.558 +graphic: 0.288 +device: 0.252 +permissions: 0.224 +semantic: 0.171 +network: 0.063 +boot: 0.035 +vnc: 0.027 +files: 0.021 +PID: 0.017 +socket: 0.016 +debug: 0.011 +KVM: 0.008 +other: 0.004 + +/usr/share/applications/qemu.desktop should have an "Exec=" key. diff --git a/results/classifier/zero-shot/108/none/45 b/results/classifier/zero-shot/108/none/45 new file mode 100644 index 000000000..32110c58a --- /dev/null +++ b/results/classifier/zero-shot/108/none/45 @@ -0,0 +1,16 @@ +device: 0.568 +graphic: 0.441 +performance: 0.376 +boot: 0.375 +semantic: 0.344 +other: 0.324 +debug: 0.273 +files: 0.165 +network: 0.148 +PID: 0.140 +socket: 0.116 +permissions: 0.078 +vnc: 0.050 +KVM: 0.044 + +qemu-system-aarch64: no function defined to set boot device list for this architecture diff --git a/results/classifier/zero-shot/108/none/452 b/results/classifier/zero-shot/108/none/452 new file mode 100644 index 000000000..d79d4e702 --- /dev/null +++ b/results/classifier/zero-shot/108/none/452 @@ -0,0 +1,71 @@ +permissions: 0.563 +device: 0.529 +PID: 0.513 +files: 0.476 +performance: 0.460 +other: 0.446 +boot: 0.382 +graphic: 0.329 +debug: 0.297 +semantic: 0.264 +network: 0.250 +socket: 0.218 +vnc: 0.205 +KVM: 0.133 + +Akita (and probably all Spitz-like / PXA270) platform does not load BIOS binary +Description of problem: +QEMU does not appear to load a binary file passed with the "-bios" argument for the "akita" target. This probably extends to other spitz-type systems. + +Exptected behavior: qemu loads the binary into address 0x0000. +Actual behavior: address space at 0x0000 contains only zeros. +Steps to reproduce: +Terminal 1: +``` +qemu-system-arm -M akita -bios c750.rom -s -S +``` + +Terminal 2: +``` +gdb-multiarch +target remote localhost:1234 +x/64i $pc +``` + +Result: +``` +=> 0x0: andeq r0, r0, r0 + 0x4: andeq r0, r0, r0 + 0x8: andeq r0, r0, r0 + 0xc: andeq r0, r0, r0 + 0x10: andeq r0, r0, r0 +``` + +Correct behavior (can demonstrate with virt machine): +Same as before, but start Terminal 1 with: +``` +qemu-system-arm -M akita -bios c750.rom -s -S +``` + +Result: +``` +=> 0x0: b 0x34 + 0x4: ldr pc, [pc, #156] ; 0xa8 + 0x8: ldr pc, [pc, #156] ; 0xac + 0xc: ldr pc, [pc, #156] ; 0xb0 + 0x10: ldr pc, [pc, #156] ; 0xb4 + 0x14: nop ; (mov r0, r0) + 0x18: ldr pc, [pc, #152] ; 0xb8 + 0x1c: ldr pc, [pc, #152] ; 0xbc + 0x20: mov r0, #128 ; 0x80 + 0x24: b 0x2c + 0x28: mov r0, #129 ; 0x81 + 0x2c: ldr r1, [pc, #140] ; 0xc0 + 0x30: str r0, [r1] + 0x34: mrs lr, CPSR + 0x38: bic lr, lr, #31 + 0x3c: orr lr, lr, #211 ; 0xd3 + 0x40: msr CPSR_fc, lr +``` +Additional information: +File with very tiny boot ROM: [c750-tiny.rom](/uploads/045852c8b353174bf0b7a4193d0d1be0/c750-tiny.rom) diff --git a/results/classifier/zero-shot/108/none/455 b/results/classifier/zero-shot/108/none/455 new file mode 100644 index 000000000..0724d0cd5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/455 @@ -0,0 +1,49 @@ +graphic: 0.493 +other: 0.439 +device: 0.418 +semantic: 0.342 +PID: 0.219 +socket: 0.175 +performance: 0.167 +network: 0.155 +KVM: 0.143 +boot: 0.135 +debug: 0.108 +permissions: 0.097 +vnc: 0.092 +files: 0.055 + +Pressing special keys (specially ctrl) sticks the key or makes it repeat the next key until ESC or Ctrl is pressed. +Description of problem: +Well, I'm using it in a daily basis, since it is my VM to isolate the environment for work. + +It was compiled from source for _jack_ support, the only thing that I cared about. I'll be honest : I don't remember the special parameters, nothing unusual though. I'm not in the need for _rt_ kernels. + +When I press `Ctrl` and sometimes when I press other special keys, one of the three options occur : +1. It repeats all the keys pressed next, like if I was pressing it for a long time. + - Example : `a` turns into `aaaaaaaaaaaaaaa...`(continues) + - It repeats until I press `Esc` or `Ctrl` again. +1. `Ctrl` continues as pressed and everything I type occurs with `Ctrl`. + - Example : `a` turns into `Ctrl-A` + - Probably caused by the previous option. +1. It does what is expected, like `Ctrl-C` +Steps to reproduce: +1. Run the specified config. +1. Test `Ctrl-C` + `Ctrl-V` using text editors. + - I think that using a graphical one is faster to see it happening. + - Examples + - Atom + - Eclipse + - Kate + - VsCode + - It also occurred using a _pty_ but since I generally use the _middle-mouse-button_ with _ptys_. + - I'm not aware of the frequency that it happens. + - It also occurs with the mouse (`Ctrl-mouseclick`). + - For example: instead of going to a _Firefox_'s tab, it selects it. + +I don't know any other step here, the use case is trivial coding. +Additional information: +- I have already tried to disable "keyboard repeat" in config. + - At first it seems to work but the `Ctrl` key can get stuck like in the description and then I'm unable to get out of it (everything is sent as if it was with `Ctrl`) without pressing `Ctrl`+`ESC`. I have no idea of why. + - The problem seems to occur less frequently. +- It also happened before setting up `qemu-guest-agent`. diff --git a/results/classifier/zero-shot/108/none/462 b/results/classifier/zero-shot/108/none/462 new file mode 100644 index 000000000..65de2ec82 --- /dev/null +++ b/results/classifier/zero-shot/108/none/462 @@ -0,0 +1,58 @@ +performance: 0.566 +debug: 0.566 +graphic: 0.540 +device: 0.516 +network: 0.479 +semantic: 0.479 +files: 0.477 +permissions: 0.472 +PID: 0.462 +vnc: 0.429 +socket: 0.417 +KVM: 0.402 +boot: 0.375 +other: 0.271 + +mirror: the block-job-cancel command can put qemu to the endless error loop +Description of problem: +If the destination VM will crash (or network is down) right before the completion of the block device mirroring job (`block-job-cancel`), then there will be a possibility to put QEMU in the error loop. +Steps to reproduce: +1. Run both QEMU VMs: source + target. +2. On the target side prepare NBD server for blockdev mirroring process by using QMP commands similar to the one below: +``` +{"execute": "nbd-server-start", "arguments": { "addr": { "data": { "host": "::", "port": "49153" }, "type": "inet" } } } +{ "execute": "nbd-server-add", "arguments": { "device": "drive_main01", "writable": true } } +``` +3. On the source side, prepare VM for the migration and start driver mirror job: +``` +{"execute":"migrate-set-capabilities","arguments":{"capabilities":[{"capability":"pause-before-switchover","state":true}]}} +{ "execute": "drive-mirror", "arguments": { "device": "drive_main01", "mode": "existing", "job-id": "job0", "target": "nbd:127.0.0.1:49153:exportname=drive_main01", "sync": "top", "on-source-error": "stop", "on-target-error": "stop", "format": "raw", "speed": 0 } } +``` +4. On the source side wait for the `BLOCK_JOB_READY` event: +``` +{"timestamp": {"seconds": 1625586327, "microseconds": 833805}, "event": "BLOCK_JOB_READY", "data": {"device": "job0", "len": 21474836480, "offset": 21474836480, "speed": 0, "type": "mirror"}} +``` +5. Start migration on the source side: +``` +{ "execute": "migrate", "arguments": { "uri": "tcp:127.0.0.1:8091" } } +``` +6. Wait for the `pre-switchover` state of the migration: +``` +{ "execute": "query-migrate" } +{"return": {"expected-downtime": 300, "status": "pre-switchover", "setup-time": 3, "total-time": 11343, "ram": {"total": 8725020672, "postcopy-requests": 0, "dirty-sync-count": 2, "multifd-bytes": 0, "pages-per-second": 39550, "page-size": 4096, "remaining": 2871296, "mbps": 1073.7734399999999, "transferred": 963647065, "duplicate": 1899491, "dirty-pages-rate": 84, "skipped": 0, "normal-bytes": 944705536, "normal": 230641}}} +``` +7. Kill target QEMU to reproduce an issue. +8. Cancel the job on the source side: +``` +{ "execute": "block-job-cancel", "arguments": { "device": "job0" } } +``` + +Got the endless errror loop: +``` +... +{"timestamp": {"seconds": 1625586487, "microseconds": 413847}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413865}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413885}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +... +``` +Source qemu could be stopped only by using SIGKILL. diff --git a/results/classifier/zero-shot/108/none/47 b/results/classifier/zero-shot/108/none/47 new file mode 100644 index 000000000..fad382faa --- /dev/null +++ b/results/classifier/zero-shot/108/none/47 @@ -0,0 +1,16 @@ +graphic: 0.415 +semantic: 0.381 +other: 0.320 +device: 0.293 +network: 0.258 +performance: 0.221 +permissions: 0.210 +debug: 0.191 +files: 0.147 +vnc: 0.095 +boot: 0.079 +socket: 0.070 +KVM: 0.035 +PID: 0.028 + +A typo in target/riscv/insn32-64.decode diff --git a/results/classifier/zero-shot/108/none/485258 b/results/classifier/zero-shot/108/none/485258 new file mode 100644 index 000000000..3bc439c58 --- /dev/null +++ b/results/classifier/zero-shot/108/none/485258 @@ -0,0 +1,50 @@ +device: 0.580 +vnc: 0.531 +network: 0.530 +graphic: 0.505 +performance: 0.416 +boot: 0.368 +PID: 0.332 +semantic: 0.332 +permissions: 0.293 +files: 0.269 +other: 0.212 +socket: 0.197 +debug: 0.118 +KVM: 0.046 + +64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue screen after running network test + +64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue screen after running network test + +Steps to recreate: +1) install qemu frm git clone git://git.savannah.nongnu.org/qemu.git + +2)Download Soap Stone Benchmark(http://soap-stone.sourceforge.net/) and IBM java 1.4 for windows + +3)use win2k3r2sp2 64-bit as the server and win2k3r2sp2 32-bit as client (this bug does not occur when win2k3r2sp2 64-bit is the client) + +4) Running the test will reset the network interface on the server(win2k3r2sp264bit). + +5)Then shutdown the server(win2k3r2sp2 64bit), which will generate a blue screen. + + +Qemu cmd line used: +/usr/local/bin/qemu-system-x86_e 'vm1' -drive file=win2003r2-64.raw,boot=on -net nic,vlan=0,macaddr=20:20:20:00:00:01,model=rtl8139 -net tap,vlan=0,script=/home/yogi/qemu-ifup -m 10240 -usbdevice tablet -vnc :0 -enable-kvm + +uname -a +Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 x86_64 x86_64 GNU/Linux + +Distro: fedora 11 + +I have attached the generated Blue Screen.. + +Thx +yogi + + + +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/zero-shot/108/none/490 b/results/classifier/zero-shot/108/none/490 new file mode 100644 index 000000000..41efb6eb1 --- /dev/null +++ b/results/classifier/zero-shot/108/none/490 @@ -0,0 +1,844 @@ +permissions: 0.541 +device: 0.398 +other: 0.397 +graphic: 0.384 +KVM: 0.366 +semantic: 0.350 +vnc: 0.346 +boot: 0.336 +socket: 0.334 +PID: 0.324 +files: 0.322 +debug: 0.320 +performance: 0.290 +network: 0.253 + +Compilation FAILED: libblock.fa.p/block_vpc.c.o +Description of problem: +Compilation failed +Steps to reproduce: +``` +git checkout v5.2.0 +./configure --target-list=riscv64-softmmu +make +``` +Additional information: +``` +changing dir to build for make ""... +make[1]: Entering directory '/home/peterlin/Labs/riscv64-linux/qemu/build' +/usr/bin/ninja build.ninja && touch build.ninja.stamp +ninja: no work to do. +/usr/bin/meson introspect --targets --tests --benchmarks | /usr/bin/python3 -B scripts/mtest2make.py > Makefile.mtest + AS multiboot.o + AS linuxboot.o + CC linuxboot_dma.o + AS pvh.o + AS kvmvapic.o + BUILD linuxboot.img + BUILD kvmvapic.img + CC pvh_main.o + BUILD multiboot.img + BUILD linuxboot_dma.img +ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) +make[2]: *** [Makefile:57: kvmvapic.img] Error 1 +make[2]: *** Waiting for unfinished jobs.... +ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) +make[2]: *** [Makefile:57: linuxboot.img] Error 1 +ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) +ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) +make[2]: *** [Makefile:57: multiboot.img] Error 1 +make[2]: *** [Makefile:57: linuxboot_dma.img] Error 1 +make[1]: *** [Makefile:206: pc-bios/optionrom/all] Error 2 +make[1]: *** Waiting for unfinished jobs.... +[1/2124] Compiling C object libcapstone.a.p/capstone_MCInstrDesc.c.o +[2/2124] Compiling C object libcapstone.a.p/capstone_MCRegisterInfo.c.o +[3/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86Module.c.o +[4/2124] Compiling C object libcapstone.a.p/capstone_SStream.c.o +[5/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86InstPrinterCommon.c.o +[6/2124] Compiling C object libcapstone.a.p/capstone_utils.c.o +[7/2124] Compiling C object libcapstone.a.p/capstone_MCInst.c.o +[8/2124] Compiling C object libcapstone.a.p/capstone_cs.c.o +[9/2124] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +[10/2124] Generating hmp-commands.h with a custom command (wrapped by meson to capture output) +[11/2124] Generating qemu-img-cmds.h with a custom command (wrapped by meson to capture output) +[12/2124] Generating hmp-commands-info.h with a custom command (wrapped by meson to capture output) +[13/2124] Generating qemu-options.def with a custom command (wrapped by meson to capture output) +[14/2124] Compiling C object contrib/libvhost-user/libvhost-user.a.p/libvhost-user-glib.c.o +[15/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86Disassembler.c.o +[16/2124] Generating trace-hw_audio.h with a custom command (wrapped by meson to capture output) +[17/2124] Generating trace-hw_9pfs.h with a custom command (wrapped by meson to capture output) +[18/2124] Generating trace-hw_audio.c with a custom command (wrapped by meson to capture output) +[19/2124] Generating trace-hw_block_dataplane.h with a custom command (wrapped by meson to capture output) +[20/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86ATTInstPrinter.c.o +[21/2124] Generating trace-hw_block.c with a custom command (wrapped by meson to capture output) +[22/2124] Generating trace-hw_block.h with a custom command (wrapped by meson to capture output) +[23/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86IntelInstPrinter.c.o +[24/2124] Generating trace-hw_arm.h with a custom command (wrapped by meson to capture output) +[25/2124] Generating trace-hw_alpha.c with a custom command (wrapped by meson to capture output) +[26/2124] Generating trace-hw_arm.c with a custom command (wrapped by meson to capture output) +[27/2124] Compiling C object contrib/libvhost-user/libvhost-user.a.p/libvhost-user.c.o +[28/2124] Linking static target contrib/libvhost-user/libvhost-user.a +[29/2124] Generating trace-hw_char.c with a custom command (wrapped by meson to capture output) +[30/2124] Generating trace-hw_9pfs.c with a custom command (wrapped by meson to capture output) +[31/2124] Generating trace-hw_block_dataplane.c with a custom command (wrapped by meson to capture output) +[32/2124] Generating trace-hw_char.h with a custom command (wrapped by meson to capture output) +[33/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86Mapping.c.o +[34/2124] Generating trace-hw_alpha.h with a custom command (wrapped by meson to capture output) +[35/2124] Generating trace-hw_acpi.c with a custom command (wrapped by meson to capture output) +[36/2124] Generating trace-hw_acpi.h with a custom command (wrapped by meson to capture output) +[37/2124] Generating trace-accel_kvm.h with a custom command (wrapped by meson to capture output) +[38/2124] Generating trace-root.c with a custom command (wrapped by meson to capture output) +[39/2124] Generating trace-accel_tcg.h with a custom command (wrapped by meson to capture output) +[40/2124] Generating trace-accel_kvm.c with a custom command (wrapped by meson to capture output) +[41/2124] Generating trace-crypto.h with a custom command (wrapped by meson to capture output) +[42/2124] Generating trace-accel_tcg.c with a custom command (wrapped by meson to capture output) +[43/2124] Generating trace-crypto.c with a custom command (wrapped by meson to capture output) +[44/2124] Generating trace-authz.c with a custom command (wrapped by meson to capture output) +[45/2124] Generating trace-authz.h with a custom command (wrapped by meson to capture output) +[46/2124] Generating trace-monitor.h with a custom command (wrapped by meson to capture output) +[47/2124] Generating trace-monitor.c with a custom command (wrapped by meson to capture output) +[48/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86DisassemblerDecoder.c.o +[49/2124] Linking static target libcapstone.a +[50/2124] Generating trace-root.h with a custom command (wrapped by meson to capture output) +[51/2124] Generating trace-block.h with a custom command (wrapped by meson to capture output) +[52/2124] Generating trace-hw_watchdog.h with a custom command (wrapped by meson to capture output) +[53/2124] Generating trace-hw_virtio.c with a custom command (wrapped by meson to capture output) +[54/2124] Generating trace-hw_watchdog.c with a custom command (wrapped by meson to capture output) +[55/2124] Generating trace-block.c with a custom command (wrapped by meson to capture output) +[56/2124] Generating trace-io.c with a custom command (wrapped by meson to capture output) +[57/2124] Generating trace-nbd.h with a custom command (wrapped by meson to capture output) +[58/2124] Generating trace-nbd.c with a custom command (wrapped by meson to capture output) +[59/2124] Generating trace-io.h with a custom command (wrapped by meson to capture output) +[60/2124] Generating trace-scsi.h with a custom command (wrapped by meson to capture output) +[61/2124] Generating trace-scsi.c with a custom command (wrapped by meson to capture output) +[62/2124] Generating trace-audio.h with a custom command (wrapped by meson to capture output) +[63/2124] Generating trace-backends.h with a custom command (wrapped by meson to capture output) +[64/2124] Generating trace-backends.c with a custom command (wrapped by meson to capture output) +[65/2124] Generating trace-audio.c with a custom command (wrapped by meson to capture output) +[66/2124] Generating trace-backends_tpm.h with a custom command (wrapped by meson to capture output) +[67/2124] Generating trace-backends_tpm.c with a custom command (wrapped by meson to capture output) +[68/2124] Generating shared QAPI source files with a custom command +[69/2124] Generating trace-chardev.h with a custom command (wrapped by meson to capture output) +[70/2124] Generating trace-chardev.c with a custom command (wrapped by meson to capture output) +[71/2124] Generating trace-hw_display.h with a custom command (wrapped by meson to capture output) +[72/2124] Generating trace-hw_display.c with a custom command (wrapped by meson to capture output) +[73/2124] Generating trace-hw_dma.h with a custom command (wrapped by meson to capture output) +[74/2124] Generating trace-hw_dma.c with a custom command (wrapped by meson to capture output) +[75/2124] Generating trace-hw_hppa.h with a custom command (wrapped by meson to capture output) +[76/2124] Generating trace-hw_hppa.c with a custom command (wrapped by meson to capture output) +[77/2124] Generating trace-hw_hyperv.h with a custom command (wrapped by meson to capture output) +[78/2124] Generating trace-hw_hyperv.c with a custom command (wrapped by meson to capture output) +[79/2124] Generating trace-hw_i2c.h with a custom command (wrapped by meson to capture output) +[80/2124] Generating trace-hw_i386_xen.c with a custom command (wrapped by meson to capture output) +[81/2124] Generating trace-hw_i386.h with a custom command (wrapped by meson to capture output) +[82/2124] Generating trace-hw_i386.c with a custom command (wrapped by meson to capture output) +[83/2124] Generating trace-hw_i2c.c with a custom command (wrapped by meson to capture output) +[84/2124] Generating trace-hw_i386_xen.h with a custom command (wrapped by meson to capture output) +[85/2124] Generating trace-hw_ide.c with a custom command (wrapped by meson to capture output) +[86/2124] Generating trace-hw_ide.h with a custom command (wrapped by meson to capture output) +[87/2124] Generating trace-hw_input.h with a custom command (wrapped by meson to capture output) +[88/2124] Generating trace-hw_input.c with a custom command (wrapped by meson to capture output) +[89/2124] Generating trace-hw_isa.h with a custom command (wrapped by meson to capture output) +[90/2124] Generating trace-hw_intc.h with a custom command (wrapped by meson to capture output) +[91/2124] Generating trace-hw_intc.c with a custom command (wrapped by meson to capture output) +[92/2124] Generating trace-hw_mem.h with a custom command (wrapped by meson to capture output) +[93/2124] Generating trace-hw_mem.c with a custom command (wrapped by meson to capture output) +[94/2124] Generating trace-hw_isa.c with a custom command (wrapped by meson to capture output) +[95/2124] Generating trace-hw_misc.h with a custom command (wrapped by meson to capture output) +[96/2124] Generating trace-hw_mips.h with a custom command (wrapped by meson to capture output) +[97/2124] Generating trace-hw_mips.c with a custom command (wrapped by meson to capture output) +[98/2124] Generating trace-hw_misc.c with a custom command (wrapped by meson to capture output) +[99/2124] Generating trace-hw_misc_macio.c with a custom command (wrapped by meson to capture output) +[100/2124] Generating trace-hw_misc_macio.h with a custom command (wrapped by meson to capture output) +[101/2124] Generating trace-hw_net.h with a custom command (wrapped by meson to capture output) +[102/2124] Generating trace-hw_nvram.h with a custom command (wrapped by meson to capture output) +[103/2124] Generating trace-hw_net.c with a custom command (wrapped by meson to capture output) +[104/2124] Generating trace-hw_pci.h with a custom command (wrapped by meson to capture output) +[105/2124] Generating trace-hw_nvram.c with a custom command (wrapped by meson to capture output) +[106/2124] Generating trace-hw_pci_host.h with a custom command (wrapped by meson to capture output) +[107/2124] Generating trace-hw_pci.c with a custom command (wrapped by meson to capture output) +[108/2124] Generating trace-hw_pci_host.c with a custom command (wrapped by meson to capture output) +[109/2124] Generating trace-hw_ppc.h with a custom command (wrapped by meson to capture output) +[110/2124] Generating trace-hw_ppc.c with a custom command (wrapped by meson to capture output) +[111/2124] Generating trace-hw_rdma.c with a custom command (wrapped by meson to capture output) +[112/2124] Generating trace-hw_rdma_vmw.c with a custom command (wrapped by meson to capture output) +[113/2124] Generating trace-hw_rdma_vmw.h with a custom command (wrapped by meson to capture output) +[114/2124] Generating trace-hw_rdma.h with a custom command (wrapped by meson to capture output) +[115/2124] Generating trace-hw_rtc.h with a custom command (wrapped by meson to capture output) +[116/2124] Generating trace-hw_rtc.c with a custom command (wrapped by meson to capture output) +[117/2124] Generating trace-hw_s390x.c with a custom command (wrapped by meson to capture output) +[118/2124] Generating trace-hw_s390x.h with a custom command (wrapped by meson to capture output) +[119/2124] Generating trace-hw_scsi.c with a custom command (wrapped by meson to capture output) +[120/2124] Generating trace-hw_scsi.h with a custom command (wrapped by meson to capture output) +[121/2124] Generating trace-hw_sd.h with a custom command (wrapped by meson to capture output) +[122/2124] Generating trace-hw_sd.c with a custom command (wrapped by meson to capture output) +[123/2124] Generating trace-hw_sparc.h with a custom command (wrapped by meson to capture output) +[124/2124] Generating trace-hw_sparc64.c with a custom command (wrapped by meson to capture output) +[125/2124] Generating trace-hw_sparc.c with a custom command (wrapped by meson to capture output) +[126/2124] Generating trace-hw_sparc64.h with a custom command (wrapped by meson to capture output) +[127/2124] Generating trace-hw_ssi.h with a custom command (wrapped by meson to capture output) +[128/2124] Generating trace-hw_ssi.c with a custom command (wrapped by meson to capture output) +[129/2124] Generating trace-hw_timer.h with a custom command (wrapped by meson to capture output) +[130/2124] Generating trace-hw_timer.c with a custom command (wrapped by meson to capture output) +[131/2124] Generating trace-hw_tpm.h with a custom command (wrapped by meson to capture output) +[132/2124] Generating trace-hw_usb.h with a custom command (wrapped by meson to capture output) +[133/2124] Generating trace-hw_tpm.c with a custom command (wrapped by meson to capture output) +[134/2124] Generating trace-hw_usb.c with a custom command (wrapped by meson to capture output) +[135/2124] Generating trace-hw_vfio.c with a custom command (wrapped by meson to capture output) +[136/2124] Generating trace-hw_vfio.h with a custom command (wrapped by meson to capture output) +[137/2124] Generating trace-hw_xen.h with a custom command (wrapped by meson to capture output) +[138/2124] Generating trace-hw_virtio.h with a custom command (wrapped by meson to capture output) +[139/2124] Generating trace-hw_xen.c with a custom command (wrapped by meson to capture output) +[140/2124] Generating trace-hw_gpio.h with a custom command (wrapped by meson to capture output) +[141/2124] Generating trace-hw_gpio.c with a custom command (wrapped by meson to capture output) +[142/2124] Generating trace-migration.h with a custom command (wrapped by meson to capture output) +[143/2124] Generating trace-net.c with a custom command (wrapped by meson to capture output) +[144/2124] Generating trace-migration.c with a custom command (wrapped by meson to capture output) +[145/2124] Generating trace-softmmu.h with a custom command (wrapped by meson to capture output) +[146/2124] Generating trace-net.h with a custom command (wrapped by meson to capture output) +[147/2124] Generating trace-softmmu.c with a custom command (wrapped by meson to capture output) +[148/2124] Generating trace-ui.h with a custom command (wrapped by meson to capture output) +[149/2124] Generating trace-ui.c with a custom command (wrapped by meson to capture output) +[150/2124] Generating trace-hw_core.c with a custom command (wrapped by meson to capture output) +[151/2124] Generating trace-hw_core.h with a custom command (wrapped by meson to capture output) +[152/2124] Generating trace-qapi.h with a custom command (wrapped by meson to capture output) +[153/2124] Generating trace-qom.h with a custom command (wrapped by meson to capture output) +[154/2124] Generating trace-qapi.c with a custom command (wrapped by meson to capture output) +[155/2124] Generating trace-qom.c with a custom command (wrapped by meson to capture output) +[156/2124] Generating trace-target_arm.h with a custom command (wrapped by meson to capture output) +[157/2124] Generating trace-target_arm.c with a custom command (wrapped by meson to capture output) +[158/2124] Generating trace-target_hppa.h with a custom command (wrapped by meson to capture output) +[159/2124] Generating trace-target_hppa.c with a custom command (wrapped by meson to capture output) +[160/2124] Generating trace-target_i386.h with a custom command (wrapped by meson to capture output) +[161/2124] Generating trace-target_i386.c with a custom command (wrapped by meson to capture output) +[162/2124] Generating trace-target_mips.h with a custom command (wrapped by meson to capture output) +[163/2124] Generating trace-target_ppc.h with a custom command (wrapped by meson to capture output) +[164/2124] Generating trace-target_mips.c with a custom command (wrapped by meson to capture output) +[165/2124] Generating trace-target_ppc.c with a custom command (wrapped by meson to capture output) +[166/2124] Generating trace-target_riscv.h with a custom command (wrapped by meson to capture output) +[167/2124] Generating trace-target_riscv.c with a custom command (wrapped by meson to capture output) +[168/2124] Generating trace-target_s390x.h with a custom command (wrapped by meson to capture output) +[169/2124] Generating trace-target_s390x.c with a custom command (wrapped by meson to capture output) +[170/2124] Generating trace-target_sparc.h with a custom command (wrapped by meson to capture output) +[171/2124] Generating trace-util.h with a custom command (wrapped by meson to capture output) +[172/2124] Generating trace-target_sparc.c with a custom command (wrapped by meson to capture output) +[173/2124] Generating trace-util.c with a custom command (wrapped by meson to capture output) +[174/2124] Generating generated-helpers.c with a custom command (wrapped by meson to capture output) +[175/2124] Generating generated-tcg-tracers.h with a custom command (wrapped by meson to capture output) +[176/2124] Generating generated-helpers.h with a custom command (wrapped by meson to capture output) +[177/2124] Generating trace-events-all with a custom command (wrapped by meson to capture output) +[178/2124] Generating generated-helpers-wrappers.h with a custom command (wrapped by meson to capture output) +[179/2124] Generating input-keymap-linux-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[180/2124] Generating input-keymap-qcode-to-atset1.c.inc with a custom command (wrapped by meson to capture output) +[181/2124] Generating input-keymap-qcode-to-atset2.c.inc with a custom command (wrapped by meson to capture output) +[182/2124] Generating input-keymap-atset1-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[183/2124] Generating input-keymap-qcode-to-linux.c.inc with a custom command (wrapped by meson to capture output) +[184/2124] Generating input-keymap-qcode-to-qnum.c.inc with a custom command (wrapped by meson to capture output) +[185/2124] Generating input-keymap-qcode-to-atset3.c.inc with a custom command (wrapped by meson to capture output) +[186/2124] Generating input-keymap-qcode-to-sun.c.inc with a custom command (wrapped by meson to capture output) +[187/2124] Generating input-keymap-qnum-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[188/2124] Generating input-keymap-win32-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[189/2124] Generating input-keymap-usb-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[190/2124] Generating module_block.h with a custom command +[191/2124] Generating block-gen.c with a custom command +[192/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128_lt_quiet.c.o +[193/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128_isSignalingNaN.c.o +[194/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_i64.c.o +[195/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_ui32.c.o +[196/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_ui64.c.o +[197/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_i32.c.o +[198/2124] Generating 'libqemu-riscv64-softmmu.fa.p/decode-insn16.c.inc'. +[199/2124] Generating input-keymap-xorgevdev-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[200/2124] Generating input-keymap-xorgxwin-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[201/2124] Generating texture-blit-frag.h with a custom command (wrapped by meson to capture output) +[202/2124] Generating texture-blit-vert.h with a custom command (wrapped by meson to capture output) +[203/2124] Generating input-keymap-xorgxquartz-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[204/2124] Generating input-keymap-xorgkbd-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[205/2124] Generating 'libqemu-riscv64-softmmu.fa.p/decode-insn32.c.inc'. +[206/2124] Generating input-keymap-x11-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[207/2124] Generating QGA QAPI files with a custom command +[208/2124] Generating bepo with a custom command +[209/2124] Generating input-keymap-osx-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[210/2124] Generating ar with a custom command +[211/2124] Generating cz with a custom command +[212/2124] Generating texture-blit-flip-vert.h with a custom command (wrapped by meson to capture output) +[213/2124] Generating de with a custom command +[214/2124] Generating da with a custom command +[215/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/download.c.o +[216/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/addrspace.c.o +[217/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/qemu_elf.c.o +[218/2124] Compiling C object contrib/ivshmem-client/ivshmem-client.p/main.c.o +[219/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/pdb.c.o +[220/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-qdev.c.o +[221/2124] Compiling C object libqemuutil.a.p/stubs_ram-block.c.o +[222/2124] Generating riscv64-softmmu-gdbstub-xml.c with a custom command (wrapped by meson to capture output) +[223/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-acpi.c.o +[224/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-acpi.c.o +[225/2124] Compiling C object contrib/ivshmem-client/ivshmem-client.p/ivshmem-client.c.o +[226/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-acpi.c.o +[227/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-acpi.c.o +[228/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/main.c.o +[229/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-authz.c.o +[230/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-builtin-types.c.o +[231/2124] Generating QAPI files for qemu-storage-daemon with a custom command +[232/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-audio.c.o +[233/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_mips.c.o +[234/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-builtin-visit.c.o +[235/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-audio.c.o +[236/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-authz.c.o +[237/2124] Compiling C object libblock.fa.p/block_qed-check.c.o +[238/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-audio.c.o +[239/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-authz.c.o +[240/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-misc.c.o +[241/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-user-input-pci.c.o +[242/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-audio.c.o +[243/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-block.c.o +[244/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-vsock-common.c.o +[245/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-block.c.o +[246/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-authz.c.o +[247/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-input-host-pci.c.o +[248/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-block.c.o +[249/2124] Compiling C object libblock.fa.p/block_qed-cluster.c.o +[250/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-authz.c.o +[251/2124] Compiling C object libblock.fa.p/block_qed-l2-cache.c.o +[252/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-block.c.o +[253/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-block-export.c.o +[254/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-misc.c.o +[255/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-block.c.o +[256/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-block-export.c.o +[257/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-rng-pci.c.o +[258/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-char.c.o +[259/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-char.c.o +[260/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-block-core.c.o +[261/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-block-export.c.o +[262/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-block-export.c.o +[263/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-common.c.o +[264/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-common.c.o +[265/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-common.c.o +[266/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-common.c.o +[267/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-char.c.o +[268/2124] Compiling C object libqemuutil.a.p/util_getauxval.c.o +[269/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-char.c.o +[270/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-control.c.o +[271/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-block-core.c.o +[272/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-control.c.o +[273/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-control.c.o +[274/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-block-core.c.o +[275/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-control.c.o +[276/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-user-vsock-pci.c.o +[277/2124] Compiling C object libqemuutil.a.p/util_uuid.c.o +[278/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-user-blk-pci.c.o +[279/2124] Compiling C object libqemuutil.a.p/util_rcu.c.o +[280/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-crypto.c.o +[281/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-crypto.c.o +[282/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-crypto.c.o +[283/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-dump.c.o +[284/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-error.c.o +[285/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-dump.c.o +[286/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-dump.c.o +[287/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-error.c.o +[288/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-dump.c.o +[289/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-error.c.o +[290/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-error.c.o +[291/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-introspect.c.o +[292/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-introspect.c.o +[293/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-introspect.c.o +[294/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-crypto.c.o +[295/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-job.c.o +[296/2124] Compiling C object libqemuutil.a.p/stubs_cpu-get-clock.c.o +[297/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-job.c.o +[298/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-job.c.o +[299/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-job.c.o +[300/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-machine.c.o +[301/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-misc.c.o +[302/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-migration.c.o +[303/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-introspect.c.o +[304/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-migration.c.o +[305/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-machine.c.o +[306/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-balloon-pci.c.o +[307/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-crypto.c.o +[308/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-machine.c.o +[309/2124] Compiling C object libqemuutil.a.p/util_crc32c.c.o +[310/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-monitor.c.o +[311/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-9p-pci.c.o +[312/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-migration.c.o +[313/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-migration.c.o +[314/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-pragma.c.o +[315/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-scsi-pci.c.o +[316/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-net.c.o +[317/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-pragma.c.o +[318/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-net.c.o +[319/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-net.c.o +[320/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-pragma.c.o +[321/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-pragma.c.o +[322/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-misc.c.o +[323/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-qdev.c.o +[324/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-qdev.c.o +[325/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-qom.c.o +[326/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-pci.c.o +[327/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-qdev.c.o +[328/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-net.c.o +[329/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-qom.c.o +[330/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-pci.c.o +[331/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-pci.c.o +[332/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-machine.c.o +[333/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-rdma.c.o +[334/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-rocker.c.o +[335/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-rdma.c.o +[336/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-rdma.c.o +[337/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-qom.c.o +[338/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-pci.c.o +[339/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-qom.c.o +[340/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-rdma.c.o +[341/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-replay.c.o +[342/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-replay.c.o +[343/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-replay.c.o +[344/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-replay.c.o +[345/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-rocker.c.o +[346/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-rocker.c.o +[347/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-run-state.c.o +[348/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-rocker.c.o +[349/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-run-state.c.o +[350/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-sockets.c.o +[351/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-sockets.c.o +[352/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-sockets.c.o +[353/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-run-state.c.o +[354/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-tpm.c.o +[355/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-tpm.c.o +[356/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-run-state.c.o +[357/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-trace.c.o +[358/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-trace.c.o +[359/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-tpm.c.o +[360/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-sockets.c.o +[361/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-trace.c.o +[362/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-tpm.c.o +[363/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-transaction.c.o +[364/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-trace.c.o +[365/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-transaction.c.o +[366/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-ui.c.o +[367/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-transaction.c.o +[368/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-ui.c.o +[369/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-root.c.o +[370/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-accel_kvm.c.o +[371/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-transaction.c.o +[372/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-ui.c.o +[373/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-accel_tcg.c.o +[374/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-nbd.c.o +[375/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-audio.c.o +[376/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-io.c.o +[377/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-scsi.c.o +[378/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-backends.c.o +[379/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-chardev.c.o +[380/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-backends_tpm.c.o +[381/2124] Compiling C object libblock.fa.p/block_dmg-bz2.c.o +[382/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_9pfs.c.o +[383/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_acpi.c.o +[384/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_alpha.c.o +[385/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_audio.c.o +[386/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_block_dataplane.c.o +[387/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_arm.c.o +[388/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_char.c.o +[389/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_block.c.o +[390/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_hyperv.c.o +[391/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_dma.c.o +[392/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_display.c.o +[393/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_i2c.c.o +[394/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-ui.c.o +[395/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_hppa.c.o +[396/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_ide.c.o +[397/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_i386_xen.c.o +[398/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_i386.c.o +[399/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_input.c.o +[400/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_mem.c.o +[401/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_isa.c.o +[402/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_nvram.c.o +[403/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_intc.c.o +[404/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_misc_macio.c.o +[405/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_misc.c.o +[406/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_pci_host.c.o +[407/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_pci.c.o +[408/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_ppc.c.o +[409/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_rdma.c.o +[410/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_rdma_vmw.c.o +[411/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_net.c.o +[412/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_s390x.c.o +[413/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_rtc.c.o +[414/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_sparc.c.o +[415/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-block-core.c.o +[416/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_sd.c.o +[417/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_timer.c.o +[418/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_sparc64.c.o +[419/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_scsi.c.o +[420/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_tpm.c.o +[421/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_ssi.c.o +[422/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_virtio.c.o +[423/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_xen.c.o +[424/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_vfio.c.o +[425/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_usb.c.o +[426/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_watchdog.c.o +[427/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_gpio.c.o +[428/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-ui.c.o +[429/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-qapi.c.o +[430/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-net.c.o +[431/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-softmmu.c.o +[432/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_core.c.o +[433/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-migration.c.o +[434/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-qom.c.o +[435/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_arm.c.o +[436/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_hppa.c.o +[437/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_mips.c.o +[438/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_i386.c.o +[439/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_riscv.c.o +[440/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_ppc.c.o +[441/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-util.c.o +[442/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_s390x.c.o +[443/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_sparc.c.o +[444/2124] Compiling C object libqemuutil.a.p/qapi_qapi-dealloc-visitor.c.o +[445/2124] Compiling C object libqemuutil.a.p/qapi_qapi-util.c.o +[446/2124] Compiling C object libqemuutil.a.p/qapi_qapi-clone-visitor.c.o +[447/2124] Compiling C object libqemuutil.a.p/qapi_qmp-event.c.o +[448/2124] Compiling C object libqemuutil.a.p/qapi_opts-visitor.c.o +[449/2124] Compiling C object libqemuutil.a.p/qapi_qmp-dispatch.c.o +[450/2124] Compiling C object libqemuutil.a.p/qobject_qnull.c.o +[451/2124] Compiling C object libqemuutil.a.p/qapi_qobject-output-visitor.c.o +[452/2124] Compiling C object libqemuutil.a.p/qapi_qmp-registry.c.o +[453/2124] Compiling C object libqemuutil.a.p/qapi_string-input-visitor.c.o +[454/2124] Compiling C object libqemuutil.a.p/qobject_qstring.c.o +[455/2124] Compiling C object libqemuutil.a.p/qobject_qnum.c.o +[456/2124] Compiling C object libqemuutil.a.p/qapi_string-output-visitor.c.o +[457/2124] Compiling C object libqemuutil.a.p/qobject_qobject.c.o +[458/2124] Compiling C object libqemuutil.a.p/qobject_qbool.c.o +[459/2124] Compiling C object libqemuutil.a.p/qapi_qapi-visit-core.c.o +[460/2124] Compiling C object libqemuutil.a.p/qobject_qlist.c.o +[461/2124] Compiling C object libqemuutil.a.p/qapi_qobject-input-visitor.c.o +[462/2124] Compiling C object libqemuutil.a.p/qobject_qlit.c.o +[463/2124] Compiling C object libqemuutil.a.p/qobject_json-lexer.c.o +[464/2124] Compiling C object libqemuutil.a.p/qobject_qdict.c.o +[465/2124] Compiling C object libqemuutil.a.p/qobject_qjson.c.o +[466/2124] Compiling C object libqemuutil.a.p/util_unicode.c.o +[467/2124] Compiling C object libqemuutil.a.p/qobject_json-streamer.c.o +[468/2124] Compiling C object libqemuutil.a.p/util_qemu-timer-common.c.o +[469/2124] Compiling C object libqemuutil.a.p/util_fdmon-poll.c.o +[470/2124] Compiling C object libqemuutil.a.p/qobject_json-parser.c.o +[471/2124] Compiling C object libqemuutil.a.p/util_compatfd.c.o +[472/2124] Compiling C object libqemuutil.a.p/util_event_notifier-posix.c.o +[473/2124] Compiling C object libqemuutil.a.p/util_fdmon-epoll.c.o +[474/2124] Compiling C object libqemuutil.a.p/util_qemu-openpty.c.o +[475/2124] Compiling C object libqemuutil.a.p/qobject_block-qdict.c.o +[476/2124] Compiling C object libqemuutil.a.p/util_mmap-alloc.c.o +[477/2124] Compiling C object libqemuutil.a.p/util_fdmon-io_uring.c.o +[478/2124] Compiling C object libqemuutil.a.p/util_osdep.c.o +[479/2124] Compiling C object libqemuutil.a.p/util_module.c.o +[480/2124] Compiling C object libqemuutil.a.p/util_cutils.c.o +[481/2124] Compiling C object libqemuutil.a.p/util_host-utils.c.o +[482/2124] Compiling C object libqemuutil.a.p/util_memfd.c.o +[483/2124] Compiling C object libqemuutil.a.p/util_envlist.c.o +[484/2124] Compiling C object libqemuutil.a.p/util_path.c.o +[485/2124] Compiling C object libqemuutil.a.p/util_aio-posix.c.o +[486/2124] Compiling C object libqemuutil.a.p/util_fifo8.c.o +[487/2124] Compiling C object libqemuutil.a.p/util_bitops.c.o +[488/2124] Compiling C object libqemuutil.a.p/util_cacheinfo.c.o +[489/2124] Compiling C object libqemuutil.a.p/util_qemu-thread-posix.c.o +[490/2124] Compiling C object libqemuutil.a.p/util_id.c.o +[491/2124] Compiling C object libqemuutil.a.p/util_qemu-print.c.o +[492/2124] Compiling C object libqemuutil.a.p/util_oslib-posix.c.o +[493/2124] Compiling C object libqemuutil.a.p/util_error.c.o +[494/2124] Compiling C object libqemuutil.a.p/util_notify.c.o +[495/2124] Compiling C object libqemuutil.a.p/util_qemu-progress.c.o +[496/2124] Compiling C object libqemuutil.a.p/util_bitmap.c.o +[497/2124] Compiling C object libqemuutil.a.p/util_qemu-error.c.o +[498/2124] Compiling C object libqemuutil.a.p/util_keyval.c.o +[499/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-input-pci.c.o +[500/2124] Compiling C object libqemuutil.a.p/util_qemu-config.c.o +[501/2124] Compiling C object libqemuutil.a.p/util_pagesize.c.o +[502/2124] Compiling C object libqemuutil.a.p/util_log.c.o +[503/2124] Compiling C object libqemuutil.a.p/util_range.c.o +[504/2124] Compiling C object libqemuutil.a.p/util_drm.c.o +[505/2124] Compiling C object libqemuutil.a.p/util_stats64.c.o +[506/2124] Compiling C object libqemuutil.a.p/util_qdist.c.o +[507/2124] Compiling C object libqemuutil.a.p/util_systemd.c.o +[508/2124] Compiling C object libqemuutil.a.p/util_aiocb.c.o +[509/2124] Compiling C object libblock.fa.p/block_dmg.c.o +[510/2124] Compiling C object libqemuutil.a.p/util_guest-random.c.o +[511/2124] Compiling C object libqemuutil.a.p/util_base64.c.o +[512/2124] Compiling C object libqemuutil.a.p/util_qht.c.o +[513/2124] Compiling C object libqemuutil.a.p/util_aio-wait.c.o +[514/2124] Compiling C object libqemuutil.a.p/util_async.c.o +[515/2124] Compiling C object libqemuutil.a.p/util_qemu-option.c.o +[516/2124] Compiling C object libqemuutil.a.p/util_dbus.c.o +[517/2124] Compiling C object libqemuutil.a.p/util_qsp.c.o +[518/2124] Compiling C object libqemuutil.a.p/util_hexdump.c.o +[519/2124] Compiling C object libblock.fa.p/block_curl.c.o +[520/2124] Compiling C object libqemuutil.a.p/util_coroutine-ucontext.c.o +[521/2124] Compiling C object libqemuutil.a.p/util_buffer.c.o +[522/2124] Compiling C object libqemuutil.a.p/util_iova-tree.c.o +[523/2124] Compiling C object libqemuutil.a.p/util_main-loop.c.o +[524/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine-io.c.o +[525/2124] Compiling C object libqemuutil.a.p/util_lockcnt.c.o +[526/2124] Compiling C object libqemuutil.a.p/util_nvdimm-utils.c.o +[527/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine.c.o +[528/2124] Compiling C object libqemuutil.a.p/util_iov.c.o +[529/2124] Compiling C object libqemuutil.a.p/util_hbitmap.c.o +[530/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine-sleep.c.o +[531/2124] Compiling C object libqemuutil.a.p/util_bufferiszero.c.o +[532/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine-lock.c.o +[533/2124] Compiling C object libqemuutil.a.p/util_block-helpers.c.o +[534/2124] Compiling C object libqemuutil.a.p/util_qemu-co-shared-resource.c.o +[535/2124] Compiling C object libqemuutil.a.p/util_vhost-user-server.c.o +[536/2124] Compiling C object libqemuutil.a.p/util_qemu-sockets.c.o +[537/2124] Compiling C object libqemuutil.a.p/util_timed-average.c.o +[538/2124] Compiling C object libqemuutil.a.p/crypto_random-gnutls.c.o +[539/2124] Compiling C object libqemuutil.a.p/crypto_init.c.o +[540/2124] Compiling C object libqemuutil.a.p/util_filemonitor-inotify.c.o +[541/2124] Compiling C object libqemuutil.a.p/util_readline.c.o +[542/2124] Compiling C object libqemuutil.a.p/util_thread-pool.c.o +[543/2124] Compiling C object libqemuutil.a.p/stubs_arch_type.c.o +[544/2124] Compiling C object libqemuutil.a.p/util_qemu-timer.c.o +[545/2124] Compiling C object libqemuutil.a.p/crypto_aes.c.o +[546/2124] Compiling C object libqemuutil.a.p/trace_qmp.c.o +[547/2124] Compiling C object libqemuutil.a.p/util_throttle.c.o +[548/2124] Compiling C object libqemuutil.a.p/util_uri.c.o +[549/2124] Compiling C object libqemuutil.a.p/stubs_blockdev-close-all-bdrv-states.c.o +[550/2124] Compiling C object libqemuutil.a.p/stubs_bdrv-next-monitor-owned.c.o +[551/2124] Compiling C object libqemuutil.a.p/stubs_blk-exp-close-all.c.o +[552/2124] Compiling C object libqemuutil.a.p/stubs_change-state-handler.c.o +[553/2124] Compiling C object libqemuutil.a.p/stubs_blk-commit-all.c.o +[554/2124] Compiling C object libqemuutil.a.p/stubs_cpus-get-virtual-clock.c.o +[555/2124] Compiling C object libqemuutil.a.p/stubs_cmos.c.o +[556/2124] Compiling C object libqemuutil.a.p/stubs_qemu-timer-notify-cb.c.o +[557/2124] Compiling C object libqemuutil.a.p/stubs_dump.c.o +[558/2124] Compiling C object libqemuutil.a.p/trace_control.c.o +[559/2124] Compiling C object libqemuutil.a.p/util_vfio-helpers.c.o +[560/2124] Compiling C object libqemuutil.a.p/stubs_error-printf.c.o +[561/2124] Compiling C object libqemuutil.a.p/stubs_gdbstub.c.o +[562/2124] Compiling C object libqemuutil.a.p/stubs_icount.c.o +[563/2124] Compiling C object libqemuutil.a.p/stubs_io_uring.c.o +[564/2124] Compiling C object libqemuutil.a.p/stubs_iothread.c.o +[565/2124] Compiling C object libqemuutil.a.p/stubs_get-vm-name.c.o +[566/2124] Compiling C object libqemuutil.a.p/stubs_fw_cfg.c.o +[567/2124] Compiling C object libqemuutil.a.p/stubs_is-daemonized.c.o +[568/2124] Compiling C object libqemuutil.a.p/stubs_iothread-lock.c.o +[569/2124] Compiling C object libqemuutil.a.p/stubs_fdset.c.o +[570/2124] Compiling C object libqemuutil.a.p/stubs_machine-init-done.c.o +[571/2124] Compiling C object libqemuutil.a.p/stubs_migr-blocker.c.o +[572/2124] Compiling C object libqemuutil.a.p/stubs_linux-aio.c.o +[573/2124] Compiling C object libqemuutil.a.p/stubs_isa-bus.c.o +[574/2124] Compiling C object libqemuutil.a.p/stubs_runstate-check.c.o +[575/2124] Compiling C object libqemuutil.a.p/stubs_qtest.c.o +[576/2124] Compiling C object libqemuutil.a.p/stubs_monitor.c.o +[577/2124] Compiling C object libqemuutil.a.p/stubs_ramfb.c.o +[578/2124] Compiling C object libqemuutil.a.p/stubs_pci-bus.c.o +[579/2124] Compiling C object libqemuutil.a.p/stubs_qmp_memory_device.c.o +[580/2124] Compiling C object libqemuutil.a.p/stubs_monitor-core.c.o +[581/2124] Compiling C object libqemuutil.a.p/stubs_sysbus.c.o +[582/2124] Compiling C object libqemuutil.a.p/stubs_pci-host-piix.c.o +[583/2124] Compiling C object libqemuutil.a.p/stubs_replay.c.o +[584/2124] Compiling C object libqemuutil.a.p/stubs_target-monitor-defs.c.o +[585/2124] Compiling C object libqemuutil.a.p/stubs_set-fd-handler.c.o +[586/2124] Compiling C object libqemuutil.a.p/stubs_target-get-monitor-def.c.o +[587/2124] Compiling C object libqemuutil.a.p/stubs_tpm.c.o +[588/2124] Compiling C object libqemuutil.a.p/stubs_trace-control.c.o +[589/2124] Compiling C object libqemuutil.a.p/stubs_uuid.c.o +[590/2124] Compiling C object libqemuutil.a.p/stubs_vmstate.c.o +[591/2124] Compiling C object libqemuutil.a.p/stubs_vm-stop.c.o +[592/2124] Compiling C object libqemuutil.a.p/stubs_win32-kbd-hook.c.o +[593/2124] Compiling C object libcommon.fa.p/hw_net_rocker_rocker_of_dpa.c.o +[594/2124] Compiling C object libqemuutil.a.p/stubs_vmgenid.c.o +[595/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_cpu.c.o +[596/2124] Compiling C object libqemuutil.a.p/stubs_cpu-synchronize-state.c.o +[597/2124] Compiling C object libqemuutil.a.p/stubs_replay-tools.c.o +[598/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_fpu_helper.c.o +[599/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_csr.c.o +[600/2124] Compiling C object libqemuutil.a.p/stubs_semihost.c.o +[601/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/qos_external.c.o +[602/2124] Compiling C object fsdev/virtfs-proxy-helper.p/9p-marshal.c.o +[603/2124] Compiling C object libqemuutil.a.p/stubs_xen-hw-stub.c.o +[604/2124] Compiling C object fsdev/virtfs-proxy-helper.p/9p-iov-marshal.c.o +[605/2124] Compiling C object fsdev/virtfs-proxy-helper.p/virtfs-proxy-helper.c.o +[606/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc-spapr.c.o +[607/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/libqos.c.o +[608/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc.c.o +[609/2124] Linking static target libqemuutil.a +[610/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/rtas.c.o +[611/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/fw_cfg.c.o +[612/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/libqos-spapr.c.o +[613/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/qgraph.c.o +[614/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/pci.c.o +[615/2124] Linking target fsdev/virtfs-proxy-helper +[616/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/pci-spapr.c.o +[617/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc-pc.c.o +[618/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/libqos-pc.c.o +[619/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/usb.c.o +[620/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/pci-pc.c.o +[621/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/e1000e.c.o +[622/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_cpu_helper.c.o +[623/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/i2c.c.o +[624/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/i2c-omap.c.o +[625/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/i2c-imx.c.o +[626/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/tpci200.c.o +[627/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/.._libqtest.c.o +[628/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-balloon.c.o +[629/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-9p.c.o +[630/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-blk.c.o +[631/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/sdhci.c.o +[632/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-mmio.c.o +[633/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-rng.c.o +[634/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/aarch64-xlnx-zcu102-machine.c.o +[635/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-imx25-pdk-machine.c.o +[636/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-net.c.o +[637/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-scsi.c.o +[638/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-n800-machine.c.o +[639/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio.c.o +[640/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-serial.c.o +[641/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-pci-modern.c.o +[642/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-smdkc210-machine.c.o +[643/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-raspi2-machine.c.o +[644/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-sabrelite-machine.c.o +[645/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-xilinx-zynq-a9-machine.c.o +[646/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-pci.c.o +[647/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/ppc64_pseries-machine.c.o +[648/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-virt-machine.c.o +[649/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/x86_64_pc-machine.c.o +[650/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/ahci.c.o +[651/2124] Compiling C object libqom.fa.p/qom_container.c.o +[652/2124] Compiling C object libauthz.fa.p/authz_base.c.o +[653/2124] Linking static target tests/qtest/libqos/libqos.fa +[654/2124] Compiling C object libqom.fa.p/qom_qom-qobject.c.o +[655/2124] Compiling C object libqom.fa.p/hw_nvram_fw_cfg-interface.c.o +[656/2124] Generating block.syms with a custom command (wrapped by meson to capture output) +[657/2124] Compiling C object libauthz.fa.p/authz_simple.c.o +[658/2124] Compiling C object libqom.fa.p/qom_object_interfaces.c.o +[659/2124] Compiling C object libauthz.fa.p/authz_list.c.o +[660/2124] Generating qemu.syms with a custom command (wrapped by meson to capture output) +[661/2124] Compiling C object libauthz.fa.p/authz_listfile.c.o +[662/2124] Compiling C object libauthz.fa.p/authz_pamacct.c.o +[663/2124] Linking static target libauthz.fa +[664/2124] Compiling C object libcrypto.fa.p/crypto_afsplit.c.o +[665/2124] Compiling C object libcrypto.fa.p/crypto_block-qcow.c.o +[666/2124] Compiling C object libcrypto.fa.p/crypto_hash.c.o +[667/2124] Compiling C object libcrypto.fa.p/crypto_ivgen-plain64.c.o +[668/2124] Compiling C object libcrypto.fa.p/crypto_block.c.o +[669/2124] Compiling C object libcrypto.fa.p/crypto_ivgen-essiv.c.o +[670/2124] Compiling C object libcrypto.fa.p/crypto_hmac.c.o +[671/2124] Compiling C object libcrypto.fa.p/crypto_ivgen-plain.c.o +[672/2124] Compiling C object libcrypto.fa.p/crypto_desrfb.c.o +[673/2124] Compiling C object libcrypto.fa.p/crypto_ivgen.c.o +[674/2124] Compiling C object libcrypto.fa.p/crypto_pbkdf.c.o +[675/2124] Compiling C object libcrypto.fa.p/crypto_secret.c.o +[676/2124] Compiling C object libcrypto.fa.p/crypto_tlscreds.c.o +[677/2124] Compiling C object libcrypto.fa.p/crypto_secret_common.c.o +[678/2124] Compiling C object libcrypto.fa.p/crypto_tlscredsanon.c.o +[679/2124] Compiling C object libcrypto.fa.p/crypto_hash-nettle.c.o +[680/2124] Compiling C object libcrypto.fa.p/crypto_tlscredspsk.c.o +[681/2124] Compiling C object libcrypto.fa.p/crypto_block-luks.c.o +[682/2124] Compiling C object libcrypto.fa.p/crypto_pbkdf-nettle.c.o +[683/2124] Compiling C object libcrypto.fa.p/crypto_secret_keyring.c.o +[684/2124] Compiling C object libcrypto.fa.p/crypto_tlscredsx509.c.o +[685/2124] Compiling C object libcrypto.fa.p/crypto_hmac-nettle.c.o +[686/2124] Compiling C object libio.fa.p/io_channel-command.c.o +[687/2124] Compiling C object libcrypto.fa.p/crypto_tlssession.c.o +[688/2124] Compiling C object libcrypto.fa.p/crypto_cipher.c.o +[689/2124] Compiling C object libcrypto.fa.p/crypto_tls-cipher-suites.c.o +[690/2124] Compiling C object libio.fa.p/io_channel-buffer.c.o +[691/2124] Compiling C object libmigration.fa.p/migration_page_cache.c.o +[692/2124] Compiling C object libio.fa.p/io_channel-util.c.o +[693/2124] Linking static target libcrypto.fa +[694/2124] Compiling C object libio.fa.p/io_channel-file.c.o +[695/2124] Compiling C object libio.fa.p/io_channel-watch.c.o +[696/2124] Compiling C object libqom.fa.p/qom_object.c.o +[697/2124] Compiling C object libio.fa.p/io_channel-tls.c.o +[698/2124] Linking static target libqom.fa +[699/2124] Compiling C object libio.fa.p/io_dns-resolver.c.o +[700/2124] Compiling C object libmigration.fa.p/migration_xbzrle.c.o +[701/2124] Compiling C object libio.fa.p/io_channel.c.o +[702/2124] Compiling C object libio.fa.p/io_task.c.o +[703/2124] Compiling C object libio.fa.p/io_channel-socket.c.o +[704/2124] Compiling C object libmigration.fa.p/migration_qemu-file-channel.c.o +[705/2124] Compiling C object libmigration.fa.p/migration_qjson.c.o +[706/2124] Compiling C object libio.fa.p/io_net-listener.c.o +[707/2124] Compiling C object libio.fa.p/io_channel-websock.c.o +[708/2124] Linking static target libio.fa +[709/2124] Compiling C object libblock.fa.p/replication.c.o +[710/2124] Compiling C object libmigration.fa.p/migration_vmstate.c.o +[711/2124] Compiling C object libmigration.fa.p/migration_vmstate-types.c.o +[712/2124] Compiling C object libblock.fa.p/meson-generated_.._block_block-gen.c.o +[713/2124] Compiling C object libmigration.fa.p/migration_qemu-file.c.o +[714/2124] Compiling C object libblock.fa.p/blockjob.c.o +[715/2124] Linking static target libmigration.fa +[716/2124] Compiling C object libblock.fa.p/nbd_common.c.o +[717/2124] Compiling C object libblock.fa.p/scsi_utils.c.o +[718/2124] Compiling C object libblock.fa.p/scsi_pr-manager.c.o +[719/2124] Compiling C object libblock.fa.p/block_aio_task.c.o +[720/2124] Compiling C object libblock.fa.p/block_nfs.c.o +[721/2124] Compiling C object libblock.fa.p/job.c.o +[722/2124] Compiling C object libblock.fa.p/block_amend.c.o +[723/2124] Compiling C object libblock.fa.p/scsi_pr-manager-helper.c.o +[724/2124] Compiling C object libblock.fa.p/block_accounting.c.o +[725/2124] Compiling C object libblock.fa.p/block_blklogwrites.c.o +[726/2124] Compiling C object libblock.fa.p/block_backup-top.c.o +[727/2124] Compiling C object libblock.fa.p/block_blkverify.c.o +[728/2124] Compiling C object libblock.fa.p/qemu-io-cmds.c.o +[729/2124] Compiling C object libblock.fa.p/block_backup.c.o +[730/2124] Compiling C object libblock.fa.p/block_commit.c.o +[731/2124] Compiling C object libblock.fa.p/nbd_client.c.o +[732/2124] Compiling C object libblock.fa.p/block_blkdebug.c.o +[733/2124] Compiling C object libblock.fa.p/block_create.c.o +[734/2124] Compiling C object libblock.fa.p/block_copy-on-read.c.o +[735/2124] Compiling C object libblock.fa.p/block_dirty-bitmap.c.o +[736/2124] Compiling C object libblock.fa.p/block_block-copy.c.o +[737/2124] Compiling C object libblock.fa.p/block_null.c.o +[738/2124] Compiling C object libblock.fa.p/block_filter-compress.c.o +[739/2124] Compiling C object libblock.fa.p/block_crypto.c.o +[740/2124] Compiling C object libblock.fa.p/block_qapi.c.o +[741/2124] Compiling C object libblock.fa.p/block_block-backend.c.o +[742/2124] Compiling C object libblock.fa.p/block_raw-format.c.o +[743/2124] Compiling C object libblock.fa.p/block_mirror.c.o +[744/2124] Compiling C object libblock.fa.p/block_snapshot.c.o +[745/2124] Compiling C object libblock.fa.p/block_qcow2-cache.c.o +[746/2124] Compiling C object libblock.fa.p/block_quorum.c.o +[747/2124] Compiling C object libblock.fa.p/block_nbd.c.o +[748/2124] Compiling C object libblock.fa.p/block_qcow2-bitmap.c.o +[749/2124] Compiling C object libblock.fa.p/block_throttle-groups.c.o +[750/2124] Compiling C object libblock.fa.p/block_qcow2-threads.c.o +[751/2124] Compiling C object libblock.fa.p/block_qcow2-snapshot.c.o +[752/2124] Compiling C object libblock.fa.p/block_cloop.c.o +[753/2124] Compiling C object libblock.fa.p/block_bochs.c.o +[754/2124] Compiling C object libblock.fa.p/block_vpc.c.o +FAILED: libblock.fa.p/block_vpc.c.o +cc -Ilibblock.fa.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu99 -O2 -g -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 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -isystem /home/peterlin/Labs/riscv64-linux/qemu/linux-headers -isystem linux-headers -iquote /home/peterlin/Labs/riscv64-linux/qemu/tcg/i386 -iquote . -iquote /home/peterlin/Labs/riscv64-linux/qemu -iquote /home/peterlin/Labs/riscv64-linux/qemu/accel/tcg -iquote /home/peterlin/Labs/riscv64-linux/qemu/include -iquote /home/peterlin/Labs/riscv64-linux/qemu/disas/libvixl -pthread -fPIE -DHAVE_LIBSSH_0_8 -MD -MQ libblock.fa.p/block_vpc.c.o -MF libblock.fa.p/block_vpc.c.o.d -o libblock.fa.p/block_vpc.c.o -c ../block/vpc.c +../block/vpc.c: In function ‘vpc_open’: +../block/vpc.c:358:51: error: array subscript ‘VHDDynDiskHeader {aka struct vhd_dyndisk_header}[0]’ is partly outside array bounds of ‘uint8_t[512]’ {aka ‘unsigned char[512]’} [-Werror=array-bounds] + 358 | s->block_size = be32_to_cpu(dyndisk_header->block_size); + | ^~ +../block/vpc.c:223:13: note: while referencing ‘buf’ + 223 | uint8_t buf[HEADER_SIZE]; + | ^~~ +../block/vpc.c:366:58: error: array subscript ‘VHDDynDiskHeader {aka struct vhd_dyndisk_header}[0]’ is partly outside array bounds of ‘uint8_t[512]’ {aka ‘unsigned char[512]’} [-Werror=array-bounds] + 366 | s->max_table_entries = be32_to_cpu(dyndisk_header->max_table_entries); + | ^~ +../block/vpc.c:223:13: note: while referencing ‘buf’ + 223 | uint8_t buf[HEADER_SIZE]; + | ^~~ +../block/vpc.c:398:51: error: array subscript ‘VHDDynDiskHeader {aka struct vhd_dyndisk_header}[0]’ is partly outside array bounds of ‘uint8_t[512]’ {aka ‘unsigned char[512]’} [-Werror=array-bounds] + 398 | s->bat_offset = be64_to_cpu(dyndisk_header->table_offset); + | ^~ +../block/vpc.c:223:13: note: while referencing ‘buf’ + 223 | uint8_t buf[HEADER_SIZE]; + | ^~~ +cc1: all warnings being treated as errors +[755/2124] Compiling C object libblock.fa.p/block.c.o +[756/2124] Compiling C object libblock.fa.p/block_vhdx.c.o +[757/2124] Compiling C object libblock.fa.p/block_throttle.c.o +[758/2124] Compiling C object libblock.fa.p/block_vhdx-endian.c.o +[759/2124] Compiling C object libblock.fa.p/block_io.c.o +[760/2124] Compiling C object libblock.fa.p/block_qcow2-refcount.c.o +[761/2124] Compiling C object libblock.fa.p/block_qed-table.c.o +[762/2124] Compiling C object libblock.fa.p/block_qcow2-cluster.c.o +[763/2124] Compiling C object libblock.fa.p/block_vmdk.c.o +[764/2124] Compiling C object libblock.fa.p/block_qcow2.c.o +[765/2124] Compiling C object libblock.fa.p/block_vvfat.c.o +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:171: run-ninja] Error 1 +make[1]: Leaving directory '/home/peterlin/Labs/riscv64-linux/qemu/build' +make: *** [GNUmakefile:11: all] Error 2 +``` diff --git a/results/classifier/zero-shot/108/none/491 b/results/classifier/zero-shot/108/none/491 new file mode 100644 index 000000000..621f16af7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/491 @@ -0,0 +1,16 @@ +debug: 0.578 +boot: 0.436 +socket: 0.431 +device: 0.418 +PID: 0.347 +KVM: 0.331 +vnc: 0.295 +network: 0.258 +permissions: 0.250 +other: 0.219 +performance: 0.047 +graphic: 0.038 +semantic: 0.020 +files: 0.015 + +There is a code error here diff --git a/results/classifier/zero-shot/108/none/498 b/results/classifier/zero-shot/108/none/498 new file mode 100644 index 000000000..64d639e0e --- /dev/null +++ b/results/classifier/zero-shot/108/none/498 @@ -0,0 +1,57 @@ +KVM: 0.394 +vnc: 0.283 +graphic: 0.261 +permissions: 0.179 +other: 0.148 +performance: 0.144 +boot: 0.133 +device: 0.118 +semantic: 0.109 +debug: 0.099 +network: 0.085 +files: 0.084 +PID: 0.078 +socket: 0.068 + +Cannot focus QEMU window on macOS Big Sur (11.4) +Description of problem: +I'm not sure when the problem has been started, but I recently noticed that key inputs to QEMU window are not processed and the input goes other focused windows (e.g. terminal). QEMU window itself is shown but it looks like they are not focused. Also, the Dock icon for QEMU is also disappeared (it was displayed before). +Steps to reproduce: +1. build & install the latest qemu with `./configure --target-list=x86_64-softmmu` + - (`a146af86c8247f41b641783428b95ee71eb0e43f` was the revision I used) +2. run `qemu-system-x86_64` from terminal +3. click the QEMU window. + - Expected behavior: menu bar title will be switched to "QEMU", key inputs are handled by QEMU, Dock icon will be shown. + - Actual behavior: menu bar shows different app name that were focused before clicking the qemu, key inputs went to other app that was focused, dock icon is not showing up. +Additional information: +I tried to see if the events are delivered to QemuCocoaView by putting `NSLog(@"handleEventLocked: %@\n", event);` at the beginning of `handleEventLocked` @ `ui/cocoa.m`. It looks like the mouse events are delivered but not NSEventTypeKeyDown. + +(logs after clicked the QEMU window and type some 'a') +``` +$ qemu-system-x86_64 +2021-07-24 16:58:00.767 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682409.7 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=4 data1=1144258560 data2=1138098176 +2021-07-24 16:58:00.768 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,228) time=682409.7 flags=0 win=0x7fe2b5fb0ee0 winNum=10356 ctxt=0x0 subtype=4 data1=1137180672 data2=1130627072 +2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1129 data2=0 +2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(591.031,166.896) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6096 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 +2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,0) time=0.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=1 data1=1129 data2=0 +2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=22 data1=0 data2=0 +2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=23 data1=0 data2=0 +2021-07-24 16:58:06.565 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(591.031,166.896) time=682415.5 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6096 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0 +2021-07-24 16:58:12.997 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(174.184,408.859) time=682421.9 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 +2021-07-24 16:58:13.013 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(152.704,428.804) time=682422.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 +2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1131 data2=0 +2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(268.333,208.222) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 +2021-07-24 16:58:24.262 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(268.333,208.222) time=682433.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0 +2021-07-24 16:58:24.877 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(3.83252,400.359) time=682433.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 +2021-07-24 16:58:25.053 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1 +2021-07-24 16:58:25.054 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0 +2021-07-24 16:58:25.302 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(10.917,420.558) time=682434.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 +2021-07-24 16:58:25.365 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(10.917,420.558) time=682434.3 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0 +2021-07-24 16:58:25.845 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1 +2021-07-24 16:58:25.846 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0 +2021-07-24 16:58:25.855 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(14.2417,428.558) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 + +``` + +Possibly related discussion on Apple Developer Forums: +- https://developer.apple.com/forums/thread/667004 diff --git a/results/classifier/zero-shot/108/none/498039 b/results/classifier/zero-shot/108/none/498039 new file mode 100644 index 000000000..0216e4157 --- /dev/null +++ b/results/classifier/zero-shot/108/none/498039 @@ -0,0 +1,33 @@ +device: 0.575 +graphic: 0.476 +vnc: 0.330 +semantic: 0.258 +network: 0.252 +other: 0.244 +PID: 0.229 +socket: 0.148 +debug: 0.102 +permissions: 0.091 +performance: 0.091 +boot: 0.072 +files: 0.069 +KVM: 0.053 + +No copy/paste with VNC display with Windows guest + +There is no copy/paste functionality between a Windows guest and the VNC client. This is a significant usability problem. + +One work-around is to run VNC inside of the guest. But that appears to have more overhead than qemu's VNC display. + +Obviously, qemu's VNC display is just a display device and knows absolutely nothing about the Windows clipboard. Thus, to interface with the guest's clipboard would require a helper app running in the guest that can hook into qemu. This would probably be the best solution. + +There are probably not a lot of qemu developers interested in trying to write the helper app. Not exactly an interesting job. But since it is a significant usability problem, and many users would see this as a major oversight, I suggest leaving this bug open long-term as a hint so that some volunteer later looking for something to do might take pity on everyone and write this helper app. + +The qxl display and vdagent running in guest do just this. + +Unfortunately, the options needed in qemu command line to make vdagent work with the spice client do not seem to be documented anywhere. + +see bug 1452742 + +Right, this problem should be fixed with Spice, so I'm closing this ticket now. + diff --git a/results/classifier/zero-shot/108/none/502107 b/results/classifier/zero-shot/108/none/502107 new file mode 100644 index 000000000..78eb26ba9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/502107 @@ -0,0 +1,136 @@ +semantic: 0.545 +other: 0.483 +permissions: 0.471 +debug: 0.461 +graphic: 0.342 +PID: 0.334 +network: 0.326 +device: 0.312 +performance: 0.303 +socket: 0.261 +KVM: 0.242 +vnc: 0.234 +boot: 0.229 +files: 0.228 + +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/zero-shot/108/none/509 b/results/classifier/zero-shot/108/none/509 new file mode 100644 index 000000000..bd5c9d55d --- /dev/null +++ b/results/classifier/zero-shot/108/none/509 @@ -0,0 +1,16 @@ +device: 0.545 +performance: 0.535 +graphic: 0.357 +other: 0.245 +PID: 0.096 +boot: 0.095 +permissions: 0.084 +semantic: 0.064 +network: 0.047 +vnc: 0.033 +files: 0.033 +debug: 0.027 +socket: 0.024 +KVM: 0.012 + +Atomic test-and-set instruction does not work on qemu-user diff --git a/results/classifier/zero-shot/108/none/526653 b/results/classifier/zero-shot/108/none/526653 new file mode 100644 index 000000000..b053b7f39 --- /dev/null +++ b/results/classifier/zero-shot/108/none/526653 @@ -0,0 +1,59 @@ +semantic: 0.282 +PID: 0.250 +device: 0.239 +debug: 0.211 +graphic: 0.177 +performance: 0.092 +socket: 0.089 +other: 0.088 +network: 0.077 +vnc: 0.074 +files: 0.069 +boot: 0.067 +KVM: 0.066 +permissions: 0.054 + +Breakpoint on Memory address fails with KVM + +Using QEMU version 0.12.50 under ubuntu Karmic x64 + +To reproduce the error using a floppy with a bootloder: +qemu-system-x86_64 -s -S -fda floppy.img -boot a -enable-kvm + +connect with gdb: +(gdb) set arch i8086 +The target architecture is assumed to be i8086 +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +0x0000fff0 in ?? () +(gdb) break *0x7c00 +Breakpoint 1 at 0x7c00 +(gdb) continue +Continuing. + +The breakpoint is not hit. + +If you close qemu and start it without kvm support: + +qemu-system-x86_64 -s -S -fda floppy.img -boot a + +(gdb) set arch i8086 +The target architecture is assumed to be i8086 +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +0x0000fff0 in ?? () +(gdb) break *0x7c00 +Breakpoint 1 at 0x7c00 +(gdb) continue +Continuing. + +Breakpoint 1, 0x00007c00 in ?? () +(gdb) + +The breakpoint is hit. If you wait until after the bootloader has been loaded into memory, you can properly set breakpoints with or without kvm enabled. + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (currently version 2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/538808 b/results/classifier/zero-shot/108/none/538808 new file mode 100644 index 000000000..e469413bd --- /dev/null +++ b/results/classifier/zero-shot/108/none/538808 @@ -0,0 +1,43 @@ +graphic: 0.449 +device: 0.374 +semantic: 0.373 +other: 0.347 +performance: 0.312 +socket: 0.219 +debug: 0.166 +network: 0.127 +vnc: 0.123 +PID: 0.119 +boot: 0.081 +permissions: 0.070 +files: 0.047 +KVM: 0.023 + +qemu-system-x86_64 0.12.2 crashes with -m 967 under Windows + +qemu 0.12.2 and 0.12.3 exit silently under Windows XP when using an -m value higher than 967. Any value below 967 works fine. Affects both qemu.exe and qemu-system-x86_64.exe (the only binaries currently available). +qemu 0.12.3 under Linux (Ubuntu 8.10) works fine. +Version 0.9.0 for Windows does not have this problem. I do not have any other binaries to test. + +Command used: +qemu-system-x86_64 -L . -m 967 -hda linux.img -localtime -M pc + +There is plenty of available RAM on the host PC (see attached systeminfo). +Not sure what debugging options to use, but will attach whatever is necessary. + + + +Under 1.0.1 a pop-up window reports a Vis C++ runtime error, the result is the same. -m 966 works fine. + +Can you still reproduce this problem with the latest version of QEMU? + +I think that QEMU did not crash, but simply was not able to allocate the block of memory which was requested. This is an inherent problem of the fragmented memory of 32 bit applications on Windows. + +QEMU reports problems with memory allocation, but QEMU for Windows tries to send those messages to stderr which is redirected to a file when QEMU was built with SDL2. + +So no crash and silently by design. + +64 bit versions don't have that problem, nor do my pre-built 32 bit binaries which include a patch to use upper memory. And in my latest binaries I dropped SDL support. + +I close this issue - please re-open if you think this was wrong. + diff --git a/results/classifier/zero-shot/108/none/559 b/results/classifier/zero-shot/108/none/559 new file mode 100644 index 000000000..c668490d6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/559 @@ -0,0 +1,16 @@ +network: 0.553 +device: 0.501 +performance: 0.491 +debug: 0.439 +permissions: 0.355 +semantic: 0.205 +graphic: 0.181 +boot: 0.162 +files: 0.138 +socket: 0.076 +other: 0.061 +KVM: 0.049 +vnc: 0.024 +PID: 0.017 + +info does not recognize file format of vpc with subformat=fixed diff --git a/results/classifier/zero-shot/108/none/584155 b/results/classifier/zero-shot/108/none/584155 new file mode 100644 index 000000000..5b9bb15f9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/584155 @@ -0,0 +1,28 @@ +device: 0.580 +graphic: 0.271 +boot: 0.209 +socket: 0.193 +vnc: 0.191 +semantic: 0.164 +network: 0.163 +PID: 0.076 +files: 0.074 +debug: 0.037 +other: 0.037 +permissions: 0.025 +KVM: 0.006 +performance: 0.006 + +support horisontal mouse wheel + +Brad Jorsch provided a series of patches to support horisontal mouse scrolling in qemu-emulated mouse. +See Debian bug#579968 -- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579968 and submission to qemu-devel list at http://<email address hidden>/msg30991.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/79 + + diff --git a/results/classifier/zero-shot/108/none/589827 b/results/classifier/zero-shot/108/none/589827 new file mode 100644 index 000000000..56630b5ce --- /dev/null +++ b/results/classifier/zero-shot/108/none/589827 @@ -0,0 +1,37 @@ +device: 0.490 +other: 0.485 +network: 0.462 +semantic: 0.377 +graphic: 0.360 +vnc: 0.298 +performance: 0.283 +socket: 0.267 +PID: 0.139 +files: 0.128 +boot: 0.114 +debug: 0.088 +permissions: 0.080 +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/zero-shot/108/none/591 b/results/classifier/zero-shot/108/none/591 new file mode 100644 index 000000000..fd57fc604 --- /dev/null +++ b/results/classifier/zero-shot/108/none/591 @@ -0,0 +1,16 @@ +device: 0.555 +semantic: 0.373 +graphic: 0.250 +boot: 0.243 +PID: 0.185 +network: 0.115 +vnc: 0.114 +debug: 0.110 +permissions: 0.110 +performance: 0.105 +socket: 0.099 +other: 0.068 +files: 0.043 +KVM: 0.007 + +Sphinx documentation jobs fail on fork with no version tag diff --git a/results/classifier/zero-shot/108/none/600 b/results/classifier/zero-shot/108/none/600 new file mode 100644 index 000000000..7d91b19ca --- /dev/null +++ b/results/classifier/zero-shot/108/none/600 @@ -0,0 +1,16 @@ +semantic: 0.598 +other: 0.486 +device: 0.483 +network: 0.415 +performance: 0.414 +boot: 0.332 +PID: 0.246 +graphic: 0.236 +permissions: 0.199 +files: 0.193 +vnc: 0.159 +socket: 0.115 +KVM: 0.111 +debug: 0.081 + +Have 'info mtree' accept an (optional) 'name' parameter to pick a specific address space diff --git a/results/classifier/zero-shot/108/none/602336 b/results/classifier/zero-shot/108/none/602336 new file mode 100644 index 000000000..441abd879 --- /dev/null +++ b/results/classifier/zero-shot/108/none/602336 @@ -0,0 +1,122 @@ +graphic: 0.569 +debug: 0.565 +semantic: 0.540 +other: 0.528 +device: 0.476 +PID: 0.467 +performance: 0.458 +permissions: 0.457 +network: 0.447 +vnc: 0.420 +KVM: 0.417 +boot: 0.392 +files: 0.362 +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/zero-shot/108/none/609 b/results/classifier/zero-shot/108/none/609 new file mode 100644 index 000000000..fccf2b5d8 --- /dev/null +++ b/results/classifier/zero-shot/108/none/609 @@ -0,0 +1,24 @@ +device: 0.535 +graphic: 0.415 +network: 0.277 +performance: 0.267 +socket: 0.210 +debug: 0.201 +vnc: 0.187 +boot: 0.170 +PID: 0.151 +semantic: 0.129 +files: 0.071 +permissions: 0.062 +KVM: 0.055 +other: 0.018 + +Can't build system emulation with static on qemu 6.1 +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/zero-shot/108/none/611 b/results/classifier/zero-shot/108/none/611 new file mode 100644 index 000000000..fb9a487ea --- /dev/null +++ b/results/classifier/zero-shot/108/none/611 @@ -0,0 +1,142 @@ +other: 0.363 +PID: 0.343 +semantic: 0.294 +KVM: 0.282 +permissions: 0.260 +graphic: 0.220 +debug: 0.218 +boot: 0.182 +performance: 0.175 +device: 0.158 +vnc: 0.157 +network: 0.135 +socket: 0.089 +files: 0.080 + +qemu-system-m68k: hw/scsi/scsi-disk.c assertion failure +Description of problem: +QEMU assertion failure (crash): +qemu-system-m68k: ../hw/scsi/scsi-disk.c:550: scsi_write_data: Assertion `r->req.aiocb == NULL' failed. +Steps to reproduce: +``` +$ xz -d initramfs-stress-ng.cpio.xz vmlinux-5.14-multi.xz +$ cat rootfs.ext2.xz-part? | xz -dc > rootfs.ext2 +$ qemu-system-m68k -M q800 -m 128M -serial none -serial mon:stdio -g 800x600x4 -rtc base=localtime -drive file=rootfs.ext2,format=raw -kernel vmlinux-5.14-multi -append "console=ttyS0" -initrd initramfs-stress-ng.cpio + +ABCFGHIJK +[ 0.000000] Linux version 5.14.0-multi (fthain@nippy) (m68k-linux-gnu-gcc (btc) 6.4.0, GNU ld (btc) 2.28) #5 Sat Sep 4 16:09:41 AEST 2021 +[ 0.000000] Saving 140 bytes of bootinfo +[ 0.000000] Detected Macintosh model: 35 +[ 0.000000] Apple Macintosh Quadra 800 +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000000000-0x0000007fffffffff] +[ 0.000000] Normal empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] +[ 0.000000] initrd: 07d3e000 - 07fff600 +[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 32480 +[ 0.000000] Kernel command line: console=ttyS0 +[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) +[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) +[ 0.000000] Sorting __ex_table... +[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off +[ 0.000000] Memory: 121420K/131072K available (4074K kernel code, 327K rwdata, 752K rodata, 148K init, 117K bss, 9652K reserved, 0K cma-reserved) +[ 0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 +[ 0.000000] NR_IRQS: 200 +[ 0.000000] clocksource: via1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 2439823894983 ns +[ 0.000000] Console: colour dummy device 80x25 +[ 0.010000] printk: console [ttyS0] enabled +[ 0.020000] Calibrating delay loop... 841.31 BogoMIPS (lpj=4206592) +[ 0.110000] pid_max: default: 32768 minimum: 301 +[ 0.110000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) +[ 0.110000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) +[ 0.150000] devtmpfs: initialized +[ 0.160000] random: get_random_u32 called from bucket_table_alloc.isra.28+0x70/0x1a6 with crng_init=0 +[ 0.160000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 0.160000] futex hash table entries: 256 (order: -1, 3072 bytes, linear) +[ 0.160000] NET: Registered PF_NETLINK/PF_ROUTE protocol family +[ 0.170000] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations +[ 0.170000] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations +[ 0.200000] wait_for_initramfs() called before rootfs_initcalls +[ 0.220000] NuBus: Scanning NuBus slots. +[ 0.220000] Slot 9: Board resource not found! +[ 0.220000] SCSI subsystem initialized +[ 0.240000] clocksource: Switched to clocksource via1 +[ 0.260000] NET: Registered PF_INET protocol family +[ 0.260000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) +[ 0.270000] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) +[ 0.270000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) +[ 0.270000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear) +[ 0.270000] TCP: Hash tables configured (established 1024 bind 1024) +[ 0.270000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear) +[ 0.270000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) +[ 0.270000] NET: Registered PF_UNIX/PF_LOCAL protocol family +[ 0.280000] RPC: Registered named UNIX socket transport module. +[ 0.280000] RPC: Registered udp transport module. +[ 0.280000] RPC: Registered tcp transport module. +[ 0.280000] RPC: Registered tcp NFSv4.1 backchannel transport module. +[ 0.290000] Trying to unpack rootfs image as initramfs... +[ 0.290000] workingset: timestamp_bits=30 max_order=15 bucket_order=0 +[ 0.310000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) +[ 0.310000] io scheduler mq-deadline registered +[ 0.310000] macfb: framebuffer at 0xf9001000, mapped to 0x(ptrval), size 234k +[ 0.310000] macfb: mode is 800x600x4, linelength=400 +[ 0.330000] Console: switching to colour frame buffer device 100x37 +[ 0.350000] fb0: DAFB frame buffer device +[ 0.350000] pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>) +[ 0.350000] scc.0: ttyS0 at MMIO 0x5000c022 (irq = 4, base_baud = 230400) is a Z85c30 ESCC - Serial port +[ 0.350000] scc.1: ttyS1 at MMIO 0x5000c020 (irq = 4, base_baud = 230400) is a Z85c30 ESCC - Serial port +[ 0.350000] Non-volatile memory driver v1.3 +[ 0.390000] brd: module loaded +[ 0.390000] adb: Mac II ADB Driver v1.0 for Unified ADB +[ 0.410000] Detected ADB keyboard, type ANSI. +[ 0.410000] input: ADB keyboard as /devices/virtual/input/input0 +[ 0.420000] random: fast init done +[ 0.420000] input: ADB mouse as /devices/virtual/input/input1 +[ 0.430000] Freeing initrd memory: 2820K +[ 0.430000] mac_esp: using PDMA for controller 0 +[ 0.430000] mac_esp mac_esp.0: esp0: regs[(ptrval):0] irq[19] +[ 0.430000] mac_esp mac_esp.0: esp0: is a ESP236, 16 MHz (ccf=4), SCSI ID 7 +[ 3.520000] scsi host0: esp +[ 3.530000] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 +[ 3.540000] scsi target0:0:0: Beginning Domain Validation +[ 3.540000] scsi target0:0:0: Domain Validation skipping write tests +[ 3.540000] scsi target0:0:0: Ending Domain Validation +[ 3.550000] scsi 0:0:2:0: CD-ROM QEMU QEMU CD-ROM 2.5+ PQ: 0 ANSI: 5 +[ 3.550000] scsi target0:0:2: Beginning Domain Validation +[ 3.560000] scsi target0:0:2: Domain Validation skipping write tests +[ 3.560000] scsi target0:0:2: Ending Domain Validation +[ 3.560000] sr 0:0:2:0: Power-on or device reset occurred +[ 3.570000] sr 0:0:2:0: [sr0] scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray +[ 3.570000] cdrom: Uniform CD-ROM driver Revision: 3.20 +[ 3.570000] sd 0:0:0:0: Power-on or device reset occurred +[ 3.580000] sd 0:0:0:0: [sda] 322560 512-byte logical blocks: (165 MB/158 MiB) +[ 3.580000] sd 0:0:0:0: [sda] Write Protect is off +[ 3.580000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +[ 3.590000] sd 0:0:0:0: Attached scsi generic sg0 type 0 +[ 3.590000] sr 0:0:2:0: Attached scsi generic sg1 type 5 +[ 3.590000] Onboard/comm-slot SONIC, revision 0x0004, 32 bit DMA, register offset 2 +[ 3.590000] SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3 +[ 3.600000] sd 0:0:0:0: [sda] Attached SCSI disk +[ 3.610000] aoe: AoE v85 initialised. +[ 3.610000] mousedev: PS/2 mouse device common for all mice +[ 3.610000] rtc-generic rtc-generic: registered as rtc0 +[ 3.620000] NET: Registered PF_PACKET protocol family +[ 3.630000] Freeing unused kernel image (initmem) memory: 148K +[ 3.630000] This architecture does not have kernel memory protection. +[ 3.630000] Run /init as init process +/init: line 11: ifconfig: not found +# mount /dev/sda /mnt +[ 9.030000] EXT4-fs (sda): mounting ext2 file system using the ext4 subsystem +[ 9.080000] EXT4-fs (sda): mounted filesystem without journal. Opts: (null). Quota mode: disabled. +# cd /mnt +# /root/stress-ng --mmap -1 --mmap-file --mmap-bytes=100% +stress-ng: info: [42] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor +stress-ng: info: [42] dispatching hogs: 1 mmap +qemu-system-m68k: ../hw/scsi/scsi-disk.c:550: scsi_write_data: Assertion `r->req.aiocb == NULL' failed. +Aborted +``` +Additional information: + diff --git a/results/classifier/zero-shot/108/none/636 b/results/classifier/zero-shot/108/none/636 new file mode 100644 index 000000000..c41a275e5 --- /dev/null +++ b/results/classifier/zero-shot/108/none/636 @@ -0,0 +1,371 @@ +graphic: 0.503 +performance: 0.462 +debug: 0.452 +files: 0.443 +other: 0.442 +permissions: 0.434 +KVM: 0.430 +boot: 0.371 +socket: 0.370 +vnc: 0.366 +network: 0.356 +semantic: 0.352 +PID: 0.334 +device: 0.330 + +tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd can not perform graceful shutdown +Description of problem: +Roughly once every 20 times, the [`halt`](https://gitlab.com/qemu-project/qemu/-/blob/73257aa02376829f724357094e252fc3e5dd1363/tests/acceptance/boot_linux_console.py#L522) command will not produce the desired effect, and [wait()ing](https://gitlab.com/qemu-project/qemu/-/blob/73257aa02376829f724357094e252fc3e5dd1363/tests/acceptance/boot_linux_console.py#L524) on the QEMU process to gracefully shutdown will fail. + +I was not able to see any other failure in what the test covers, except the `halt` command and the `wait()`ing. That is, the booting of the kernel and initrd, and the execution of commands to inspect the system all run without problems. +Steps to reproduce: +1. make check-venv +2. ./tests/venv/bin/avocado run tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd +Additional information: +``` +13:48:01 DEBUG| PARAMS (key=arch, path=*, default=arm) => 'arm' +13:48:01 DEBUG| PARAMS (key=cpu, path=*, default=None) => None +13:48:01 DEBUG| PARAMS (key=machine, path=*, default=raspi2b) => 'raspi2b' +13:48:01 DEBUG| PARAMS (key=qemu_bin, path=*, default=./qemu-system-arm) => './qemu-system-arm' +13:48:01 DEBUG| Test workdir initialized at: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd +13:48:08 DEBUG| QEMUMachine "default" created +13:48:08 DEBUG| QEMUMachine "default" temp_dir: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/qemu-machine-5pavn9gy +13:48:08 DEBUG| QEMUMachine "default" log_dir: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd +13:48:08 DEBUG| VM launch command: './qemu-system-arm -display none -vga none -chardev socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock -mon chardev=mon,mode=control -machine raspi2b -chardev socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off -serial chardev:console -kernel /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img -dtb /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb -initrd /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio -append printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0 -no-reboot' +13:48:08 DEBUG| >>> {'execute': 'qmp_capabilities'} +13:48:08 DEBUG| <<< {'return': {}} +13:48:08 DEBUG| [ 0.000000] Booting Linux on physical CPU 0xf00 +13:48:08 DEBUG| [ 0.000000] Linux version 4.14.98-v7+ (dom@dom-XPS-13-9370) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1200 SMP Tue Feb 12 20:27:48 GMT 2019 +13:48:08 DEBUG| [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d +13:48:08 DEBUG| [ 0.000000] CPU: div instructions available: patching division code +13:48:08 DEBUG| [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache +13:48:08 DEBUG| [ 0.000000] OF: fdt: Machine model: Raspberry Pi 2 Model B +13:48:08 DEBUG| [ 0.000000] earlycon: pl11 at MMIO 0x3f201000 (options '') +13:48:08 DEBUG| [ 0.000000] bootconsole [pl11] enabled +13:48:08 DEBUG| [ 0.000000] Memory policy: Data cache writealloc +13:48:08 DEBUG| [ 0.000000] cma: Reserved 8 MiB at 0x3b800000 +13:48:08 DEBUG| [ 0.000000] percpu: Embedded 17 pages/cpu @baf2e000 s38720 r8192 d22720 u69632 +13:48:08 DEBUG| [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 243600 +13:48:08 DEBUG| [ 0.000000] Kernel command line: printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0 +13:48:08 DEBUG| PID hash table entries: 4096 (order: 2, 16384 bytes) +13:48:08 DEBUG| Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) +13:48:08 DEBUG| Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) +13:48:08 DEBUG| Memory: 949120K/983040K available (7168K kernel code, 577K rwdata, 2080K rodata, 1024K init, 698K bss, 25728K reserved, 8192K cma-reserved) +13:48:08 DEBUG| Virtual kernel memory layout: +13:48:08 DEBUG| vector : 0xffff0000 - 0xffff1000 ( 4 kB) +13:48:08 DEBUG| fixmap : 0xffc00000 - 0xfff00000 (3072 kB) +13:48:08 DEBUG| vmalloc : 0xbc800000 - 0xff800000 (1072 MB) +13:48:08 DEBUG| lowmem : 0x80000000 - 0xbc000000 ( 960 MB) +13:48:08 DEBUG| modules : 0x7f000000 - 0x80000000 ( 16 MB) +13:48:08 DEBUG| .text : 0x80008000 - 0x80800000 (8160 kB) +13:48:08 DEBUG| .init : 0x80b00000 - 0x80c00000 (1024 kB) +13:48:08 DEBUG| .data : 0x80c00000 - 0x80c906d4 ( 578 kB) +13:48:08 DEBUG| .bss : 0x80c97ef8 - 0x80d468f0 ( 699 kB) +13:48:08 DEBUG| SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 +13:48:08 DEBUG| ftrace: allocating 25298 entries in 75 pages +13:48:09 DEBUG| Hierarchical RCU implementation. +13:48:09 DEBUG| NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 +13:48:09 DEBUG| arch_timer: cp15 timer(s) running at 62.50MHz (virt). +13:48:09 DEBUG| clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns +13:48:09 DEBUG| sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns +13:48:09 DEBUG| Switching to timer-based delay loop, resolution 16ns +13:48:09 DEBUG| Console: colour dummy device 80x30 +13:48:09 DEBUG| Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000) +13:48:09 DEBUG| pid_max: default: 32768 minimum: 301 +13:48:09 DEBUG| Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) +13:48:09 DEBUG| Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) +13:48:09 DEBUG| Disabling memory control group subsystem +13:48:09 DEBUG| CPU: Testing write buffer coherency: ok +13:48:09 DEBUG| CPU0: update cpu_capacity 1024 +13:48:09 DEBUG| CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00 +13:48:09 DEBUG| Setting up static identity map for 0x100000 - 0x10003c +13:48:09 DEBUG| Hierarchical SRCU implementation. +13:48:09 DEBUG| smp: Bringing up secondary CPUs ... +13:48:09 DEBUG| CPU1: update cpu_capacity 1024 +13:48:09 DEBUG| CPU1: thread -1, cpu 1, socket 15, mpidr 80000f01 +13:48:09 DEBUG| CPU2: update cpu_capacity 1024 +13:48:09 DEBUG| CPU2: thread -1, cpu 2, socket 15, mpidr 80000f02 +13:48:09 DEBUG| CPU3: update cpu_capacity 1024 +13:48:09 DEBUG| CPU3: thread -1, cpu 3, socket 15, mpidr 80000f03 +13:48:09 DEBUG| smp: Brought up 1 node, 4 CPUs +13:48:09 DEBUG| SMP: Total of 4 processors activated (500.00 BogoMIPS). +13:48:09 DEBUG| CPU: All CPU(s) started in SVC mode. +13:48:09 DEBUG| devtmpfs: initialized +13:48:09 DEBUG| random: get_random_u32 called from bucket_table_alloc+0xfc/0x24c with crng_init=0 +13:48:09 DEBUG| VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5 +13:48:09 DEBUG| clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +13:48:09 DEBUG| futex hash table entries: 1024 (order: 4, 65536 bytes) +13:48:09 DEBUG| pinctrl core: initialized pinctrl subsystem +13:48:09 DEBUG| NET: Registered protocol family 16 +13:48:09 DEBUG| DMA: preallocated 1024 KiB pool for atomic coherent allocations +13:48:09 DEBUG| hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers. +13:48:09 DEBUG| hw-breakpoint: maximum watchpoint size is 8 bytes. +13:48:09 DEBUG| Serial: AMBA PL011 UART driver +13:48:09 DEBUG| bcm2835-mbox 3f00b880.mailbox: mailbox enabled +13:48:09 DEBUG| bcm2835-dma 3f007000.dma: DMA legacy API manager at bc813000, dmachans=0x1 +13:48:09 DEBUG| SCSI subsystem initialized +13:48:09 DEBUG| usbcore: registered new interface driver usbfs +13:48:09 DEBUG| usbcore: registered new interface driver hub +13:48:09 DEBUG| usbcore: registered new device driver usb +13:48:09 DEBUG| raspberrypi-firmware soc:firmware: Attached to firmware from 1970-01-05 00:12 +13:48:09 DEBUG| clocksource: Switched to clocksource arch_sys_counter +13:48:09 DEBUG| VFS: Disk quotas dquot_6.6.0 +13:48:09 DEBUG| VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) +13:48:09 DEBUG| FS-Cache: Loaded +13:48:09 DEBUG| CacheFiles: Loaded +13:48:09 DEBUG| NET: Registered protocol family 2 +13:48:09 DEBUG| TCP established hash table entries: 8192 (order: 3, 32768 bytes) +13:48:09 DEBUG| TCP bind hash table entries: 8192 (order: 4, 65536 bytes) +13:48:09 DEBUG| TCP: Hash tables configured (established 8192 bind 8192) +13:48:09 DEBUG| UDP hash table entries: 512 (order: 2, 16384 bytes) +13:48:09 DEBUG| UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) +13:48:09 DEBUG| NET: Registered protocol family 1 +13:48:09 DEBUG| RPC: Registered named UNIX socket transport module. +13:48:09 DEBUG| RPC: Registered udp transport module. +13:48:09 DEBUG| RPC: Registered tcp transport module. +13:48:09 DEBUG| RPC: Registered tcp NFSv4.1 backchannel transport module. +13:48:09 DEBUG| Trying to unpack rootfs image as initramfs... +13:48:09 DEBUG| Freeing initrd memory: 3256K +13:48:09 DEBUG| hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available +13:48:09 DEBUG| workingset: timestamp_bits=14 max_order=18 bucket_order=4 +13:48:09 DEBUG| FS-Cache: Netfs 'nfs' registered for caching +13:48:09 DEBUG| NFS: Registering the id_resolver key type +13:48:09 DEBUG| Key type id_resolver registered +13:48:09 DEBUG| Key type id_legacy registered +13:48:09 DEBUG| nfs4filelayout_init: NFSv4 File Layout Driver Registering... +13:48:09 DEBUG| Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) +13:48:09 DEBUG| io scheduler noop registered +13:48:09 DEBUG| io scheduler deadline registered +13:48:09 DEBUG| io scheduler cfq registered (default) +13:48:09 DEBUG| io scheduler mq-deadline registered +13:48:09 DEBUG| io scheduler kyber registered +13:48:09 DEBUG| BCM2708FB: allocated DMA memory fb900000 +13:48:09 DEBUG| BCM2708FB: allocated DMA channel 0 @ bc813000 +13:48:09 DEBUG| Console: switching to colour frame buffer device 100x30 +13:48:09 DEBUG| bcm2835-rng 3f104000.rng: hwrng registered +13:48:09 DEBUG| vc-mem: phys_addr:0x00000000 mem_base=0x00000000 mem_size:0x00000000(0 MiB) +13:48:09 DEBUG| vc-sm: Videocore shared memory driver +13:48:09 DEBUG| gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000 +13:48:09 DEBUG| brd: module loaded +13:48:09 DEBUG| loop: module loaded +13:48:09 DEBUG| Loading iSCSI transport class v2.0-870. +13:48:09 DEBUG| libphy: Fixed MDIO Bus: probed +13:48:09 DEBUG| usbcore: registered new interface driver lan78xx +13:48:09 DEBUG| usbcore: registered new interface driver smsc95xx +13:48:09 DEBUG| dwc_otg: version 3.00a 10-AUG-2012 (platform bus) +13:48:09 DEBUG| dwc_otg 3f980000.usb: base=0xf0980000 +13:48:10 DEBUG| Core Release: 2.94a +13:48:10 DEBUG| Setting default values for core params +13:48:10 DEBUG| Finished setting default values for core params +13:48:10 DEBUG| Using Buffer DMA mode +13:48:10 DEBUG| Periodic Transfer Interrupt Enhancement - disabled +13:48:10 DEBUG| Multiprocessor Interrupt Enhancement - disabled +13:48:10 DEBUG| OTG VER PARAM: 0, OTG VER FLAG: 0 +13:48:10 DEBUG| Shared Tx FIFO mode +13:48:10 DEBUG| WARN::dwc_otg_hcd_init:1046: FIQ DMA bounce buffers: virt = 0xbb914000 dma = 0xfb914000 len=9024 +13:48:10 DEBUG| WARN::hcd_init_fiq:459: FIQ on core 1 at 0x805edb88 +13:48:10 DEBUG| WARN::hcd_init_fiq:460: FIQ ASM at 0x805edcb4 length 36 +13:48:10 DEBUG| WARN::hcd_init_fiq:486: MPHI regs_base at 0xf0006000 +13:48:10 DEBUG| dwc_otg 3f980000.usb: DWC OTG Controller +13:48:10 DEBUG| dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1 +13:48:10 DEBUG| dwc_otg 3f980000.usb: irq 62, io mem 0x00000000 +13:48:10 DEBUG| Init: Port Power? op_state=1 +13:48:10 DEBUG| Init: Power Port (1) +13:48:10 DEBUG| usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 +13:48:10 DEBUG| usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +13:48:10 DEBUG| usb usb1: Product: DWC OTG Controller +13:48:10 DEBUG| usb usb1: Manufacturer: Linux 4.14.98-v7+ dwc_otg_hcd +13:48:10 DEBUG| usb usb1: SerialNumber: 3f980000.usb +13:48:10 DEBUG| hub 1-0:1.0: USB hub found +13:48:10 DEBUG| hub 1-0:1.0: 1 port detected +13:48:10 DEBUG| usbcore: registered new interface driver usb-storage +13:48:10 DEBUG| mousedev: PS/2 mouse device common for all mice +13:48:10 DEBUG| IR NEC protocol handler initialized +13:48:10 DEBUG| IR RC5(x/sz) protocol handler initialized +13:48:10 DEBUG| IR RC6 protocol handler initialized +13:48:10 DEBUG| IR JVC protocol handler initialized +13:48:10 DEBUG| IR Sony protocol handler initialized +13:48:10 DEBUG| IR SANYO protocol handler initialized +13:48:10 DEBUG| IR Sharp protocol handler initialized +13:48:10 DEBUG| IR MCE Keyboard/mouse protocol handler initialized +13:48:10 DEBUG| IR XMP protocol handler initialized +13:48:10 DEBUG| bcm2835-wdt 3f100000.watchdog: Broadcom BCM2835 watchdog timer +13:48:10 DEBUG| bcm2835-cpufreq: min=700000 max=700000 +13:48:10 DEBUG| sdhci: Secure Digital Host Controller Interface driver +13:48:10 DEBUG| sdhci: Copyright(c) Pierre Ossman +13:48:10 DEBUG| sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe +13:48:10 DEBUG| sdhci-pltfm: SDHCI platform and OF driver helper +13:48:10 DEBUG| ledtrig-cpu: registered to indicate activity on CPUs +13:48:10 DEBUG| hidraw: raw HID events driver (C) Jiri Kosina +13:48:10 DEBUG| usbcore: registered new interface driver usbhid +13:48:10 DEBUG| usbhid: USB HID core driver +13:48:10 DEBUG| vchiq: vchiq_init_state: slot_zero = bb980000, is_master = 0 +13:48:10 DEBUG| bcm2835_vchiq 3f00b840.vchiq: failed to set channelbase +13:48:10 DEBUG| vchiq: could not load vchiq +13:48:10 DEBUG| Initializing XFRM netlink socket +13:48:10 DEBUG| NET: Registered protocol family 17 +13:48:10 DEBUG| Key type dns_resolver registered +13:48:10 DEBUG| Registering SWP/SWPB emulation handler +13:48:10 DEBUG| registered taskstats version 1 +13:48:10 DEBUG| uart-pl011 3f201000.serial: cts_event_workaround enabled +13:48:10 DEBUG| 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2 +13:48:10 DEBUG| console [ttyAMA0] enabled +13:48:10 DEBUG| console [ttyAMA0] enabled +13:48:10 DEBUG| bootconsole [pl11] disabled +13:48:10 DEBUG| bootconsole [pl11] disabled +13:48:10 DEBUG| bcm2835_thermal 3f212000.thermal: Not able to read trip_temp: -33 +13:48:10 DEBUG| bcm2835-clk 3f101000.cprman: tsens: couldn't lock PLL +13:48:10 DEBUG| bcm2835_thermal: probe of 3f212000.thermal failed with error -33 +13:48:10 DEBUG| sdhost: log_buf @ bb913000 (fb913000) +13:48:10 DEBUG| mmc0: sdhost-bcm2835 loaded - DMA enabled (>1) +13:48:10 DEBUG| of_cfs_init +13:48:10 DEBUG| of_cfs_init: OK +13:48:10 DEBUG| uart-pl011 3f201000.serial: no DMA platform data +13:48:10 DEBUG| Freeing unused kernel memory: 1024K +13:48:11 DEBUG| mount: mounting devtmpfs on /dev failed: Device or resource busy +13:48:11 DEBUG| Starting logging: OK +13:48:11 DEBUG| Initializing random number generator... random: dd: uninitialized urandom read (512 bytes read) +13:48:11 DEBUG| done. +13:48:12 DEBUG| Starting network: OK +13:48:12 DEBUG| Found console ttyAMA0 +13:48:12 DEBUG| Linux version 4.14.98-v7+ (dom@dom-XPS-13-9370) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1200 SMP Tue Feb 12 20:27:48 GMT 2019 +13:48:12 DEBUG| Boot successful. +13:48:12 DEBUG| cat /proc/cpuinfo +13:48:12 DEBUG| / # cat /proc/cpuinfo +13:48:12 DEBUG| processor : 0 +13:48:12 DEBUG| model name : ARMv7 Processor rev 5 (v7l) +13:48:12 DEBUG| BogoMIPS : 125.00 +13:48:12 DEBUG| Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm +13:48:12 DEBUG| CPU implementer : 0x41 +13:48:12 DEBUG| CPU architecture: 7 +13:48:12 DEBUG| CPU variant : 0x0 +13:48:12 DEBUG| CPU part : 0xc07 +13:48:12 DEBUG| CPU revision : 5 +13:48:12 DEBUG| processor : 1 +13:48:12 DEBUG| model name : ARMv7 Processor rev 5 (v7l) +13:48:12 DEBUG| BogoMIPS : 125.00 +13:48:12 DEBUG| Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm +13:48:12 DEBUG| CPU implementer : 0x41 +13:48:12 DEBUG| CPU architecture: 7 +13:48:12 DEBUG| CPU variant : 0x0 +13:48:12 DEBUG| CPU part : 0xc07 +13:48:12 DEBUG| CPU revision : 5 +13:48:12 DEBUG| processor : 2 +13:48:12 DEBUG| model name : ARMv7 Processor rev 5 (v7l) +13:48:12 DEBUG| BogoMIPS : 125.00 +13:48:12 DEBUG| Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm +13:48:12 DEBUG| CPU implementer : 0x41 +13:48:12 DEBUG| CPU architecture: 7 +13:48:12 DEBUG| CPU variant : 0x0 +13:48:12 DEBUG| CPU part : 0xc07 +13:48:12 DEBUG| CPU revision : 5 +13:48:12 DEBUG| processor : 3 +13:48:12 DEBUG| model name : ARMv7 Processor rev 5 (v7l) +13:48:12 DEBUG| BogoMIPS : 125.00 +13:48:12 DEBUG| Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm +13:48:12 DEBUG| CPU implementer : 0x41 +13:48:12 DEBUG| CPU architecture: 7 +13:48:12 DEBUG| CPU variant : 0x0 +13:48:12 DEBUG| CPU part : 0xc07 +13:48:12 DEBUG| CPU revision : 5 +13:48:12 DEBUG| Hardware : BCM2835 +13:48:12 DEBUG| Revision : 0000 +13:48:12 DEBUG| Serial : 0000000000000000 +13:48:12 DEBUG| cat /proc/iomem +13:48:12 DEBUG| / # cat /proc/iomem +13:48:12 DEBUG| 00000000-3bffffff : System RAM +13:48:12 DEBUG| 00008000-00afffff : Kernel code +13:48:12 DEBUG| 00c00000-00d468ef : Kernel data +13:48:12 DEBUG| 3f006000-3f006fff : dwc_otg +13:48:12 DEBUG| 3f007000-3f007eff : /soc/dma@7e007000 +13:48:12 DEBUG| 3f00b880-3f00b8bf : /soc/mailbox@7e00b880 +13:48:12 DEBUG| 3f100000-3f100027 : /soc/watchdog@7e100000 +13:48:12 DEBUG| 3f101000-3f102fff : /soc/cprman@7e101000 +13:48:12 DEBUG| 3f200000-3f2000b3 : /soc/gpio@7e200000 +13:53:12 WARNI| qemu received signal 9; command: "./qemu-system-arm -display none -vga none -chardev socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock -mon chardev=mon,mode=control -machine raspi2b -chardev socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off -serial chardev:console -kernel /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img -dtb /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb -initrd /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio -append printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0 -no-reboot" +13:53:12 ERROR| +13:53:12 ERROR| Reproduced traceback from: /var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.9/site-packages/avocado/core/test.py:794 +13:53:12 ERROR| Traceback (most recent call last): +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 514, in _do_shutdown +13:53:12 ERROR| self._soft_shutdown(timeout, has_quit) +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 497, in _soft_shutdown +13:53:12 ERROR| self._subp.wait(timeout=timeout) +13:53:12 ERROR| File "/usr/lib64/python3.9/subprocess.py", line 1189, in wait +13:53:12 ERROR| return self._wait(timeout=timeout) +13:53:12 ERROR| File "/usr/lib64/python3.9/subprocess.py", line 1909, in _wait +13:53:12 ERROR| raise TimeoutExpired(self.args, timeout) +13:53:12 ERROR| subprocess.TimeoutExpired: Command '('./qemu-system-arm', '-display', 'none', '-vga', 'none', '-chardev', 'socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock', '-mon', 'chardev=mon,mode=control', '-machine', 'raspi2b', '-chardev', 'socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off', '-serial', 'chardev:console', '-kernel', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img', '-dtb', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb', '-initrd', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio', '-append', 'printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0', '-no-reboot')' timed out after 300 seconds +13:53:12 ERROR| +13:53:12 ERROR| The above exception was the direct cause of the following exception: +13:53:12 ERROR| +13:53:12 ERROR| Traceback (most recent call last): +13:53:12 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/boot_linux_console.py", line 502, in test_arm_raspi2_initrd +13:53:12 ERROR| self.vm.wait(300) +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 561, in wait +13:53:12 ERROR| self.shutdown(has_quit=True, timeout=timeout) +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 544, in shutdown +13:53:12 ERROR| self._do_shutdown(timeout, has_quit) +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 517, in _do_shutdown +13:53:12 ERROR| raise AbnormalShutdown("Could not perform graceful shutdown") \ +13:53:12 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown +13:53:12 ERROR| +13:53:12 DEBUG| Local variables: +13:53:12 DEBUG| -> self <class 'boot_linux_console.BootLinuxConsole'>: 01-tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd +13:53:12 DEBUG| -> deb_url <class 'str'>: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb +13:53:12 DEBUG| -> deb_hash <class 'str'>: cd284220b32128c5084037553db3c482426f3972 +13:53:12 DEBUG| -> deb_path <class 'str'>: /home/cleber/avocado/data/cache/by_location/c813ab2b9e4f63b2aa876075ad70d638a31a25b7/raspberrypi-kernel_1.20190215-1_armhf.deb +13:53:12 DEBUG| -> kernel_path <class 'str'>: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img +13:53:12 DEBUG| -> dtb_path <class 'str'>: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb +13:53:12 DEBUG| -> initrd_url <class 'str'>: https://github.com/groeck/linux-build-test/raw/2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/arm/rootfs-armv7a.cpio.gz +13:53:12 DEBUG| -> initrd_hash <class 'str'>: 604b2e45cdf35045846b8bbfbf2129b1891bdc9c +13:53:12 DEBUG| -> initrd_path_gz <class 'str'>: /home/cleber/avocado/data/cache/by_location/d100d022b257e2c8f0c0c97434576ed642f9afe5/rootfs-armv7a.cpio.gz +13:53:12 DEBUG| -> initrd_path <class 'str'>: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio +13:53:12 DEBUG| -> kernel_command_line <class 'str'>: printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0 +13:53:12 DEBUG| DATA (filename=output.expected) => NOT FOUND (data sources: variant, test, file) +13:53:12 DEBUG| DATA (filename=stdout.expected) => NOT FOUND (data sources: variant, test, file) +13:53:12 DEBUG| DATA (filename=stderr.expected) => NOT FOUND (data sources: variant, test, file) +13:53:12 ERROR| Traceback (most recent call last): + +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 514, in _do_shutdown + self._soft_shutdown(timeout, has_quit) + +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 497, in _soft_shutdown + self._subp.wait(timeout=timeout) + +13:53:12 ERROR| File "/usr/lib64/python3.9/subprocess.py", line 1189, in wait + return self._wait(timeout=timeout) + +13:53:12 ERROR| File "/usr/lib64/python3.9/subprocess.py", line 1909, in _wait + raise TimeoutExpired(self.args, timeout) + +13:53:12 ERROR| subprocess.TimeoutExpired: Command '('./qemu-system-arm', '-display', 'none', '-vga', 'none', '-chardev', 'socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock', '-mon', 'chardev=mon,mode=control', '-machine', 'raspi2b', '-chardev', 'socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off', '-serial', 'chardev:console', '-kernel', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img', '-dtb', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb', '-initrd', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio', '-append', 'printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0', '-no-reboot')' timed out after 300 seconds + +13:53:12 ERROR| +The above exception was the direct cause of the following exception: + + +13:53:12 ERROR| Traceback (most recent call last): + +13:53:12 ERROR| File "/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.9/site-packages/avocado/core/test.py", line 882, in _run_avocado + raise test_exception + +13:53:12 ERROR| File "/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.9/site-packages/avocado/core/test.py", line 789, in _run_avocado + testMethod() + +13:53:12 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/boot_linux_console.py", line 502, in test_arm_raspi2_initrd + self.vm.wait(300) + +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 561, in wait + self.shutdown(has_quit=True, timeout=timeout) + +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 544, in shutdown + self._do_shutdown(timeout, has_quit) + +13:53:12 ERROR| File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 517, in _do_shutdown + raise AbnormalShutdown("Could not perform graceful shutdown") \ + +13:53:12 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown + +13:53:12 ERROR| ERROR 01-tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd -> AbnormalShutdown: Could not perform graceful shutdown +13:53:12 INFO | +``` diff --git a/results/classifier/zero-shot/108/none/636095 b/results/classifier/zero-shot/108/none/636095 new file mode 100644 index 000000000..2d6d75ae3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/636095 @@ -0,0 +1,64 @@ +vnc: 0.554 +PID: 0.470 +device: 0.458 +semantic: 0.435 +network: 0.428 +performance: 0.345 +socket: 0.320 +files: 0.295 +permissions: 0.278 +other: 0.249 +graphic: 0.216 +debug: 0.142 +boot: 0.121 +KVM: 0.098 + +tap downscript is not executed when exiting qemu through "quit" monitor command + +When you tell qemu to shutdown using the "quit" monitor command, the downscript of the tap interface is not executed. + + +To reproduce: + + +Create the test script /tmp/qemu-ifdown-test.sh : + +== +#!/bin/bash + +touch /tmp/is_this_working +== + +Run: + +== +# chmod +x /tmp/qemu-ifdown-test.sh +# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server +VNC server running on `127.0.0.1:5900' +# nc -U /tmp/monitor.socket +QEMU 0.12.5 monitor - type 'help' for more information +(qemu) quit +quit +# ls /tmp/is* +ls: cannot access /tmp/is*: No such file or directory + +== + +If I quit qemu by sending a SIGTERM instead of using the "quit" command, the downscript does get executed: + +== +# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server +VNC server running on `127.0.0.1:5900' +# killall qemu-system-x86_64 +# ls /tmp/is* +/tmp/is_this_working +== + +Issue occurs with both 0.12.3 and 0.12.5 + +Have you reported this to QEMU developers' mailing list? + +Thanks for providing instructions on how to reproduce this bug. I ran your instructions on qemu.git/master and the issue does not occur. + +QEMU 0.12.x is old, please try the latest stable release 0.15.0 or qemu.git/master. + diff --git a/results/classifier/zero-shot/108/none/643 b/results/classifier/zero-shot/108/none/643 new file mode 100644 index 000000000..b9b6cb020 --- /dev/null +++ b/results/classifier/zero-shot/108/none/643 @@ -0,0 +1,16 @@ +device: 0.451 +socket: 0.285 +network: 0.247 +graphic: 0.211 +semantic: 0.179 +vnc: 0.176 +PID: 0.148 +files: 0.133 +debug: 0.121 +boot: 0.112 +other: 0.073 +performance: 0.012 +permissions: 0.012 +KVM: 0.004 + +how to add include path and library path when building qemu-4.1.1 diff --git a/results/classifier/zero-shot/108/none/660060 b/results/classifier/zero-shot/108/none/660060 new file mode 100644 index 000000000..cc5ccee09 --- /dev/null +++ b/results/classifier/zero-shot/108/none/660060 @@ -0,0 +1,54 @@ +performance: 0.396 +boot: 0.358 +device: 0.263 +socket: 0.217 +other: 0.215 +semantic: 0.213 +vnc: 0.119 +KVM: 0.118 +permissions: 0.104 +PID: 0.104 +network: 0.080 +graphic: 0.065 +debug: 0.055 +files: 0.040 + +virtio block read errors + +Context : +- Gentoo Linux distribution on host and guests. +- qemu-kvm-0.12.5-r1 +- 2.6.34-gentoo-r11 host kernel +- 2.6.29-gentoo-r5 guest kernels +- VM boots from and uses a single virtio block device. + +On the old kvm bugtracker there was a discussion about a bug with virtio block devices : +http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2933400&group_id=180599 +I was affected (user gyver in the above discussion) and believed that the problem was fully solved : we had the read error problems on 4 physical hosts . I migrated 3 of the 4 hosts to Gentoo's qemu-kvm-0.12.5-r1 which fixed the problems and allowed us to use virtio block devices instead of emulated PIIX. + +It seems there's a corner case left or another bug with similar consequences. + +I just used a maintenance window on the last physical host (one hard disk switched for repair in a RAID1 array) to migrate the ancient kvm-85 (which worked for us with virtio) to 0.12.5. The read errors in virtio block mode came back instantly. + +We have 3 VMs on this 4th host, 2 are x86, 1 is x86_64. All of them try to boot from a virtio block device and fail to do so with Gentoo's qemu-kvm-0.12.5-r1. They report read errors on /dev/vda and remount the root fs read-only. Reconfiguring them to use emulated PIIX works. There's something interesting about PIIX mode that I'm not sure I've seen before though: there are errors reported by the ATA stack during the boot and the guest kernels switch to PIO after resetting the ide0 interface. More on that later. + +Booting all these VMs works properly with Gentoo's 0.11.1-r1 with virtio block. + +Two details that might help : +1/ +We use DRBD devices for all our virtual disks (on all 4 physical hosts), + +2/ +The "failing" host has different hardware, main differences : +- Core2 Duo architecture instead of Core i7, +- hardware RAID controller: a 3ware 8006-2LP with two SATA disks in RAID-1 mode instead of plain AHCI SATA controllers and software raid 1. +Currently the controller on the "failing" host is rebuilding the array after we switched a failing disk with a brand new one. Although there's no read error on the physical host as far as its kernel is concerned, read performance is suffering : 5MB/s top from the guest point of view with 0.11.1-r1 and virtio block with a dd if=/dev/vda (only one VM running and host idle to avoid interferences other than the RAID rebuild), ... + +This poor read performance might explain the problem we saw in the guest kernel with PIIX emulation on qemu-kvm-0.12.5-r1 (slow reads might be confused with buggy DMA transfers explaining the PIO fallback). We didn't have time to test PIIX emulation after the RAID array was fully synchronized but can do on request. + +Triaging old bug tickets ... can you still recreate this issue with the latest version of QEMU, or can we close this bug nowadays? + +You can close this bug: it has been fixed long ago. + +Thanks for your response! So I'm closing this ticket now... + diff --git a/results/classifier/zero-shot/108/none/665 b/results/classifier/zero-shot/108/none/665 new file mode 100644 index 000000000..669bb8cc4 --- /dev/null +++ b/results/classifier/zero-shot/108/none/665 @@ -0,0 +1,67 @@ +device: 0.360 +graphic: 0.288 +PID: 0.244 +socket: 0.229 +vnc: 0.177 +boot: 0.160 +files: 0.118 +semantic: 0.114 +permissions: 0.114 +other: 0.091 +network: 0.076 +performance: 0.075 +debug: 0.065 +KVM: 0.032 + +Cannot boot from emulated NVMe with seabios +Description of problem: +SeaBIOS doesn't boot from NVMe disk. + +This is regression compared to version 5.1.0. The exact same SeaBIOS binary that works with QEMU 5.1.0, doesn't detect NVMe with QEMU 6.0.0, nor QEMU 6.1.0. Booting from NVMe via OVMF works on all those versions. +Steps to reproduce: +1. Start the above command +2. Press ESC to open boot menu in SeaBIOS +3. Observe lack of NVMe entry +Additional information: +I've bisected it to this commit: +``` +7f0f1acedf159d00684d495d7a14d52220c1d16b is the first bad commit +commit 7f0f1acedf159d00684d495d7a14d52220c1d16b +Author: Klaus Jensen <k.jensen@samsung.com> +Date: Wed Jun 26 08:51:06 2019 +0200 + + hw/block/nvme: support multiple namespaces + + This adds support for multiple namespaces by introducing a new 'nvme-ns' + device model. The nvme device creates a bus named from the device name + ('id'). The nvme-ns devices then connect to this and registers + themselves with the nvme device. + + This changes how an nvme device is created. Example with two namespaces: + + -drive file=nvme0n1.img,if=none,id=disk1 + -drive file=nvme0n2.img,if=none,id=disk2 + -device nvme,serial=deadbeef,id=nvme0 + -device nvme-ns,drive=disk1,bus=nvme0,nsid=1 + -device nvme-ns,drive=disk2,bus=nvme0,nsid=2 + + The drive property is kept on the nvme device to keep the change + backward compatible, but the property is now optional. Specifying a + drive for the nvme device will always create the namespace with nsid 1. + + Signed-off-by: Klaus Jensen <k.jensen@samsung.com> + Reviewed-by: Keith Busch <kbusch@kernel.org> + Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com> + + hw/block/meson.build | 2 +- + hw/block/nvme-ns.c | 167 ++++++++++++++++++++++++++++++++++ + hw/block/nvme-ns.h | 74 +++++++++++++++ + hw/block/nvme.c | 245 ++++++++++++++++++++++++++++++++------------------ + hw/block/nvme.h | 46 +++++----- + hw/block/trace-events | 6 +- + 6 files changed, 426 insertions(+), 114 deletions(-) + create mode 100644 hw/block/nvme-ns.c + create mode 100644 hw/block/nvme-ns.h +``` + +Using `-device nvme-ns` as shown above doesn't help either. diff --git a/results/classifier/zero-shot/108/none/674740 b/results/classifier/zero-shot/108/none/674740 new file mode 100644 index 000000000..76b18b1d7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/674740 @@ -0,0 +1,37 @@ +device: 0.573 +graphic: 0.562 +semantic: 0.485 +other: 0.376 +network: 0.376 +PID: 0.256 +socket: 0.215 +vnc: 0.206 +performance: 0.167 +permissions: 0.143 +debug: 0.116 +boot: 0.092 +files: 0.074 +KVM: 0.068 + +qemu segfaults when security_model=none using virtio-9p-pci driver + +qemu version: 0.13 +commit-id: 6ed912999d6ef636a5be5ccb266d7d3c0f0310b4 + +example invocation: +$ qemu -virtfs local,path=/tmp,security_model=none,mount_tag=mmm r.img +one of the following must be specified as thesecurity option: + security_model=passthrough + security_model=mapped +Segmentation fault + +Patch is attached. Also attached is a patch that addes the space between 'the' and 'security' in 'thesecurity'. + +Does not affect trunk. + + + +Add the space in 'thesecurity'. + +Current QEMU 2.7 does not segfault here anymore, and the "thesecurity" problem is also not available in the sources anymore ==> I think this can be closed nowadays. + diff --git a/results/classifier/zero-shot/108/none/676029 b/results/classifier/zero-shot/108/none/676029 new file mode 100644 index 000000000..647fda4ef --- /dev/null +++ b/results/classifier/zero-shot/108/none/676029 @@ -0,0 +1,64 @@ +network: 0.578 +socket: 0.570 +KVM: 0.508 +device: 0.445 +performance: 0.425 +other: 0.396 +semantic: 0.377 +PID: 0.301 +debug: 0.283 +graphic: 0.276 +permissions: 0.259 +boot: 0.178 +files: 0.154 +vnc: 0.131 + +Silently fail with wrong vde socket dir + +Hi, + +Using qemu 0.12.5, kvm silently fail with exit code 1 when using -net vde and a wrong path for sock. Actually, the sock option is mean to be the socket dir of the vde_switch, not the socket itself. + +With -net vde,sock=/var/run/vde/vde0/ctl , strace ends with the following messages : + +connect(7, {sa_family=AF_FILE, path="/var/run/vde/vde0/ctl/ctl"}, 110) = -1 ENOTDIR (Not a directory) +close(7) = 0 +close(8) = 0 +exit_group(1) = ? +root ~# + +Please add a meaningful message. + +Regards, +Étienne + +Hello, + +Could you please provide more data, what kinda of system and version are you running on? + +Jes + + +There's no need to add any more specific information. The bug's in the code in qemu. + +net/vde.c: + +static int net_vde_init(VLANState *vlan, const char *model, + const char *name, const char *sock, + int port, const char *group, int mode) +{ +... + vde = vde_open(init_sock, (char *)"QEMU", &args); + if (!vde){ + return -1; + } +... +} + +There's no message generated there. Callers merely pass the failure up the road, where it's finally handled as exit(1). If _anything_ is wrong in vde_open() (which can fail due to variety of reasons, including wrong path to the listening socket and what not), nothing will indicate that, just a trivial, silent exit. + +Given that you know what the problem is, it would probably have been faster to post a patch than just updating the bug and marking it confirmed.... + +A fix for this problem has finally been contributed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7587855cd23755a7a6bd + diff --git a/results/classifier/zero-shot/108/none/687 b/results/classifier/zero-shot/108/none/687 new file mode 100644 index 000000000..94b62530d --- /dev/null +++ b/results/classifier/zero-shot/108/none/687 @@ -0,0 +1,16 @@ +device: 0.494 +semantic: 0.440 +graphic: 0.272 +permissions: 0.175 +performance: 0.174 +other: 0.060 +network: 0.023 +boot: 0.007 +vnc: 0.006 +debug: 0.005 +files: 0.005 +socket: 0.002 +KVM: 0.001 +PID: 0.001 + +what is the DMAR? diff --git a/results/classifier/zero-shot/108/none/697 b/results/classifier/zero-shot/108/none/697 new file mode 100644 index 000000000..22db6e1ae --- /dev/null +++ b/results/classifier/zero-shot/108/none/697 @@ -0,0 +1,16 @@ +device: 0.517 +performance: 0.439 +boot: 0.423 +semantic: 0.378 +debug: 0.321 +graphic: 0.230 +socket: 0.154 +other: 0.137 +KVM: 0.125 +files: 0.112 +vnc: 0.108 +PID: 0.065 +network: 0.057 +permissions: 0.043 + +linux-user create default CPU type before parsing the ELF header for specific CPU type diff --git a/results/classifier/zero-shot/108/none/735752 b/results/classifier/zero-shot/108/none/735752 new file mode 100644 index 000000000..20a129e43 --- /dev/null +++ b/results/classifier/zero-shot/108/none/735752 @@ -0,0 +1,226 @@ +KVM: 0.151 +vnc: 0.139 +other: 0.076 +PID: 0.075 +permissions: 0.069 +debug: 0.061 +graphic: 0.053 +socket: 0.052 +network: 0.051 +semantic: 0.051 +device: 0.049 +boot: 0.044 +performance: 0.042 +files: 0.028 + +qemu squeeze crashes "BUG: unable to handle kernel NULL pointer dereference at (null)" + +my virtual machine server (qemu+libvirt) regularly breaks down with such a record in the logs +I can not even ping the guest, but i can ping host, but can not do something with it (cannot ssh login for example) +And I dont know how to reproduce the problem :( + +Mar 15 17:58:04 mainhost kernel: [65866.976982] BUG: unable to handle kernel NULL pointer dereference at (null) +Mar 15 17:58:04 mainhost kernel: [65866.977422] IP: [<ffffffff8100efbe>] 0xffffffff8100efbe +Mar 15 17:58:04 mainhost kernel: [65866.977663] PGD 7387b7067 PUD 81b723067 PMD 0. +Mar 15 17:58:04 mainhost kernel: [65866.977902] Oops: 0000 [#1] SMP. +Mar 15 17:58:04 mainhost kernel: [65866.978128] last sysfs file: /sys/devices/system/cpu/cpu3/topology/thread_siblings +Mar 15 17:58:04 mainhost kernel: [65866.978572] CPU 1. +Mar 15 17:58:04 mainhost kernel: [65866.978577] Modules linked in: nfs lockd nfs_acl auth_rpcgss sunrpc ebtable_nat ebtables coretemp bridge stp llc xt_state +Mar 15 17:58:04 mainhost kernel: [65866.979737]. +Mar 15 17:58:04 mainhost kernel: [65866.979959] Pid: 3369, comm: qemu-system-x86 Not tainted 2.6.37-gentoo-r2 #2 Intel S5000VSA/S5000VSA +Mar 15 17:58:04 mainhost kernel: [65866.980085] RIP: 0010:[<ffffffff8100efbe>] [<ffffffff8100efbe>] 0xffffffff8100efbe +Mar 15 17:58:04 mainhost kernel: [65866.980085] RSP: 0018:ffff880738767a48 EFLAGS: 00010246 +Mar 15 17:58:04 mainhost kernel: [65866.980085] RAX: 0000000000000000 RBX: fffffffffffff001 RCX: ffff88081cbeb948 +Mar 15 17:58:04 mainhost kernel: [65866.980085] RDX: 0000000000000022 RSI: fffffffffffff001 RDI: ffff88081cbeb000 +Mar 15 17:58:04 mainhost kernel: [65866.980085] RBP: 0000000000000001 R08: 00000000000fee01 R09: 0000000000000022 +Mar 15 17:58:04 mainhost kernel: [65866.980085] R10: 0000008000000000 R11: ffffea0000000000 R12: ffff880818d83490 +Mar 15 17:58:04 mainhost kernel: [65866.980085] R13: 00000000155e5000 R14: 0000000000000000 R15: 0000000000000100 +Mar 15 17:58:04 mainhost kernel: [65866.980085] FS: 00007f5f25e4e700(0000) GS:ffff88009f680000(0000) knlGS:fffff80001175000 +Mar 15 17:58:04 mainhost kernel: [65866.980085] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b +Mar 15 17:58:04 mainhost kernel: [65866.980085] CR2: 0000000000000000 CR3: 0000000806be9000 CR4: 00000000000426e0 +Mar 15 17:58:04 mainhost kernel: [65866.980085] DR0: 0000000000000045 DR1: 0000000000000000 DR2: 0000000000000000 +Mar 15 17:58:04 mainhost kernel: [65866.980085] DR3: 0000000000000005 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +Mar 15 17:58:04 mainhost kernel: [65866.980085] Process qemu-system-x86 (pid: 3369, threadinfo ffff880738766000, task ffff8808203ac360) +Mar 15 17:58:04 mainhost kernel: [65866.980085] Stack: +Mar 15 17:58:04 mainhost kernel: [65866.980085] 0000000000000000 ffff8806a30f3ff8 ffff880753980000 ffffffff8100f06f +Mar 15 17:58:04 mainhost kernel: [65866.980085] 0000000000000ff8 ffff8807705d6b40 0000000000000ff8 ffffffff810123f0 +Mar 15 17:58:04 mainhost kernel: [65866.980085] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +Mar 15 17:58:04 mainhost kernel: [65866.980085] Call Trace: +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100f06f>] ? 0xffffffff8100f06f +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810123f0>] ? 0xffffffff810123f0 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100f744>] ? 0xffffffff8100f744 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100ffaf>] ? 0xffffffff8100ffaf +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810011f1>] ? 0xffffffff810011f1 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810142fc>] ? 0xffffffff810142fc +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100834d>] ? 0xffffffff8100834d +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff81011af6>] ? 0xffffffff81011af6 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100c5a7>] ? 0xffffffff8100c5a7 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff81003a85>] ? 0xffffffff81003a85 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810e19b0>] ? 0xffffffff810e19b0 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff81078cd8>] ? 0xffffffff81078cd8 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810e1a39>] ? 0xffffffff810e1a39 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810267fb>] ? 0xffffffff810267fb +Mar 15 17:58:04 mainhost kernel: [65866.980085] Code: 8b 47 50 8d 50 01 85 c0 89 57 50 75 07 41 58 e9 32 ff ff ff 5f c3 55 89 d5 53 48 89 f3 48 83 ec 08 e8 d +Mar 15 17:58:04 mainhost kernel: [65866.980085] RIP [<ffffffff8100efbe>] 0xffffffff8100efbe +Mar 15 17:58:04 mainhost kernel: [65866.980085] RSP <ffff880738767a48> +Mar 15 17:58:04 mainhost kernel: [65866.980085] CR2: 0000000000000000 +Mar 15 17:58:04 mainhost kernel: [65866.990753] ---[ end trace d147f74976c2654d ]--- + +Linux mainhost 2.6.37-gentoo-r2 #2 SMP Mon Mar 14 22:53:20 MSK 2011 x86_64 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux + +app-emulation/qemu-kvm-0.13.0-r2 +app-emulation/libvirt-0.8.8-r1 + +mainhost log # ps ax|grep qemu + 2957 ? Sl 12:28 /usr/bin/qemu-system-x86_64 --enable-kvm -S -M pc-0.13 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name dc1 -uuid f090bfc9-1cab-e4e9-51ea-80c9cc775bff -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/dc1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -boot order=c,menu=off -drive file=/dev/vm-storage/dc1,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=13,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:a1:a7,bus=pci.0,addr=0x4 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:0,password -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 + 2982 ? Rl 10:34 /usr/bin/qemu-system-x86_64 --enable-kvm -S -M pc-0.13 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name transarchive -uuid b96a3481-1ad6-9329-387e-a1504a17d0ee -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/transarchive.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -boot order=c,menu=off -drive file=/dev/vm-storage/transarchive,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=13,id=hostnet0,vhost=on,vhostfd=17 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a9:f8:06,bus=pci.0,addr=0x3 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:3,password -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 + +On Tue, Mar 15, 2011 at 9:28 PM, Aidar Kamalov +<email address hidden> wrote: +> Mar 15 17:58:04 mainhost kernel: [65866.980085] Call Trace: +> Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100f06f>] ? 0xffffffff8100f06f +> Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810123f0>] ? 0xffffffff810123f0 +> Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100f744>] ? 0xffffffff8100f744 +> Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100ffaf>] ? 0xffffffff8100ffaf + +Please compile a kernel with debug information so that the call trace +has function names. The option is CONFIG_DEBUG_INFO and can be +reached via "Kernel hacking | Compile the kernel with debug info" in +make menuconfig. + +Stefan + + +I have compiled with CONFIG_DEBUG_INFO, but core is not creating, i think i do all right: + +mainhost log # zcat /proc/config.gz |grep CONFIG_DEBUG_INFO +CONFIG_DEBUG_INFO=y +# CONFIG_DEBUG_INFO_REDUCED is not set + +mainhost log # cat /etc/security/limits.conf | grep core +# - core - limits the core file size (KB) +* soft core unlimited +mainhost log # ulimit -S -s +8192 +mainhost log # ulimit -H -s +unlimited +mainhost log # ulimit -S -s 100000 +mainhost log # ulimit -S -s +100000 +mainhost log # cat /proc/sys/kernel/core_pattern +core +mainhost log # cat /proc/sys/kernel/core_uses_pid +0 +mainhost log # ulimit -c +unlimited +mainhost log # yes & kill -ABRT `jobs -p` +[1] 3527 +mainhost log # +[1]+ Aborted (core dumped) yes + + +On Wed, Mar 16, 2011 at 8:27 PM, Aidar Kamalov +<email address hidden> wrote: +> I have compiled with CONFIG_DEBUG_INFO, but core is not creating, i +> think i do all right: +> +> mainhost log # zcat /proc/config.gz |grep CONFIG_DEBUG_INFO +> CONFIG_DEBUG_INFO=y +> # CONFIG_DEBUG_INFO_REDUCED is not set + +This looks fine + +> mainhost log # cat /etc/security/limits.conf | grep core +> # - core - limits the core file size (KB) +> * soft core unlimited +> mainhost log # ulimit -S -s +> 8192 +> mainhost log # ulimit -H -s +> unlimited +> mainhost log # ulimit -S -s 100000 +> mainhost log # ulimit -S -s +> 100000 +> mainhost log # cat /proc/sys/kernel/core_pattern +> core +> mainhost log # cat /proc/sys/kernel/core_uses_pid +> 0 +> mainhost log # ulimit -c +> unlimited +> mainhost log # yes & kill -ABRT `jobs -p` +> [1] 3527 +> mainhost log # +> [1]+ Aborted (core dumped) yes + +These are core dump options for userspace processes. You originally +posted a kernel backtrace and that is not affected by core dump +options. + +When the issue is triggered again you should see function names in the +"Call Trace:" section of the BUG output. + +Stefan + + +Issue is trigered, but there are nothing changes, i will try to get core + +Mar 16 21:50:29 mainhost kernel: [28123.087654] BUG: unable to handle kernel NULL pointer dereference at (null) +Mar 16 21:50:29 mainhost kernel: [28123.088106] IP: [<ffffffff8100fe7d>] 0xffffffff8100fe7d +Mar 16 21:50:29 mainhost kernel: [28123.088331] PGD 81a4f5067 PUD 81d08b067 PMD 0. +Mar 16 21:50:29 mainhost kernel: [28123.088555] Oops: 0000 [#1] SMP. +Mar 16 21:50:29 mainhost kernel: [28123.088776] last sysfs file: /sys/devices/system/cpu/cpu3/topology/thread_siblings +Mar 16 21:50:29 mainhost kernel: [28123.089218] CPU 2. +Mar 16 21:50:29 mainhost kernel: [28123.089223] Modules linked in: i5k_amb coretemp nfs lockd nfs_acl auth_rpcgss sunrpc ebtable_nat ebtables bridge stp llc +Mar 16 21:50:29 mainhost kernel: [28123.090526]. +Mar 16 21:50:29 mainhost kernel: [28123.090526] Pid: 2900, comm: qemu-system-x86 Not tainted 2.6.38-gentoo #2 Intel S5000VSA/S5000VSA +Mar 16 21:50:29 mainhost kernel: [28123.090526] RIP: 0010:[<ffffffff8100fe7d>] [<ffffffff8100fe7d>] 0xffffffff8100fe7d +Mar 16 21:50:29 mainhost kernel: [28123.090526] RSP: 0018:ffff88081b9b5a68 EFLAGS: 00010246 +Mar 16 21:50:29 mainhost kernel: [28123.090526] RAX: 0000000000000000 RBX: fffffffffffff001 RCX: 00000000000fee01 +Mar 16 21:50:29 mainhost kernel: [28123.090526] RDX: 0000000000000022 RSI: fffffffffffff001 RDI: ffff8807be235000 +Mar 16 21:50:29 mainhost kernel: [28123.090526] RBP: 0000000000000001 R08: 0000000000000022 R09: 0000000000000040 +Mar 16 21:50:29 mainhost kernel: [28123.090526] R10: ffff88081b9b5be8 R11: 0000000000000000 R12: 0000000000000ff8 +Mar 16 21:50:29 mainhost kernel: [28123.090526] R13: 0000000001cbf000 R14: 0000000000000013 R15: 0000000000000000 +Mar 16 21:50:29 mainhost kernel: [28123.090526] FS: 00007fd821b70700(0000) GS:ffff88009f700000(0000) knlGS:000007fffffdd000 +Mar 16 21:50:29 mainhost kernel: [28123.090526] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b +Mar 16 21:50:29 mainhost kernel: [28123.090526] CR2: 0000000000000000 CR3: 000000081d245000 CR4: 00000000000426e0 +Mar 16 21:50:29 mainhost kernel: [28123.090526] DR0: 0000000000000001 DR1: 0000000000000002 DR2: 0000000000000001 +Mar 16 21:50:29 mainhost kernel: [28123.090526] DR3: 000000000000000a DR6: 00000000ffff0ff0 DR7: 0000000000000400 +Mar 16 21:50:29 mainhost kernel: [28123.090526] Process qemu-system-x86 (pid: 2900, threadinfo ffff88081b9b4000, task ffff88081f344fa0) +Mar 16 21:50:29 mainhost kernel: [28123.090526] Stack: +Mar 16 21:50:29 mainhost kernel: [28123.090526] 8000000815be5207 ffff8806bcf93ff8 ffff88081b9d4000 ffffffff8100ff2e +Mar 16 21:50:29 mainhost kernel: [28123.090526] ffffffff8100132a ffff88074b61a460 ffff88081a508000 ffffffff8101016c +Mar 16 21:50:29 mainhost kernel: [28123.090526] 0000000001cbf000 ffffffff81014d6d 000fffff00000001 0000000000001e76 +Mar 16 21:50:29 mainhost kernel: [28123.090526] Call Trace: +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8100ff2e>] ? 0xffffffff8100ff2e +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8100132a>] ? 0xffffffff8100132a +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8101016c>] ? 0xffffffff8101016c +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff81014d6d>] ? 0xffffffff81014d6d +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810106a9>] ? 0xffffffff810106a9 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810147d0>] ? 0xffffffff810147d0 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff81014c94>] ? 0xffffffff81014c94 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8102283d>] ? 0xffffffff8102283d +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810262a1>] ? 0xffffffff810262a1 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8100d1b6>] ? 0xffffffff8100d1b6 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff81003f86>] ? 0xffffffff81003f86 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810e0b37>] ? 0xffffffff810e0b37 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff81341d8e>] ? 0xffffffff81341d8e +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810ed54c>] ? 0xffffffff810ed54c +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810ed5d5>] ? 0xffffffff810ed5d5 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810287fb>] ? 0xffffffff810287fb +Mar 16 21:50:29 mainhost kernel: [28123.090526] Code: 8b 47 50 8d 50 01 85 c0 89 57 50 75 07 41 58 e9 32 ff ff ff 5e c3 55 89 d5 53 48 89 f3 48 83 ec 08 e8 9 +Mar 16 21:50:29 mainhost kernel: [28123.090526] RIP [<ffffffff8100fe7d>] 0xffffffff8100fe7d +Mar 16 21:50:29 mainhost kernel: [28123.090526] RSP <ffff88081b9b5a68> +Mar 16 21:50:29 mainhost kernel: [28123.090526] CR2: 0000000000000000 +Mar 16 21:50:29 mainhost kernel: [28123.102127] ---[ end trace 68b482cf7220ceeb ]--- + + +well, i has downgraded to 2.6.33 and system stable for 3 days yet.. +system is halted on 2.6.36, 2,6.37 and 2.6.38 kernels + +mainhost ~ # uptime + 12:38:30 up 3 days, 2:56, 2 users, load average: 0.00, 0.00, 0.04 +mainhost ~ # uname -a +Linux mainhost 2.6.33-gentoo-r1 #4 SMP Tue Aug 24 09:53:21 MSD 2010 x86_64 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux + + +Sounds like this was a kernel bug ... you should report those to the right kernel mailing lists instead. Anyway, closing this ticket now since there hasn't been any activity since a long time. + diff --git a/results/classifier/zero-shot/108/none/752476 b/results/classifier/zero-shot/108/none/752476 new file mode 100644 index 000000000..9781ab43b --- /dev/null +++ b/results/classifier/zero-shot/108/none/752476 @@ -0,0 +1,72 @@ +graphic: 0.346 +device: 0.311 +network: 0.288 +other: 0.274 +socket: 0.241 +performance: 0.240 +PID: 0.231 +permissions: 0.220 +semantic: 0.219 +vnc: 0.212 +boot: 0.192 +debug: 0.180 +files: 0.173 +KVM: 0.137 + +monitor command mouse_button 1 moves mouse + +via the qemu -monitor interface, it is possible to move and click the mouse using +mouse_move 20000 10000 +mouse_button 1 +but the mouse_button command always moves the mouse to (0,0) making it rather unusable to (auto-)trigger any widgets in the VM from the outside. + +Would be nice to have this available for my qemu/kvm based os-autoinst testing framework. + +Hi. Thanks for reporting this issue. + +I'm able to (partly) reproduce this, but it might help if I could understand your configuration a bit more. + +Does mouse movement work for you using the normal interface (SDL or VNC)? + +Do you have the pointer device configured in an absolute mode (e.g. something like a USB tablet device)? + +Can you try the attached patch? + +Hi. + +I build a kvm-0.14 with this patch on top and it finally allowed me to issue a click using mouse_button via monitor. +Great! Thanks! + + +For my automated tests I use kvm like this: +/usr/bin/qemu-kvm -m 1024 -net user -monitor tcp:127.0.0.1:15222,server,nowait -net nic,model=virtio,macaddr=52:54:00:12:34:56 -serial file:serial0 -drive file=raid/l1,if=virtio,boot=on -boot dc -cdrom /opensuse/factory/iso/openSUSE-NET-i586-Build0046-Media.iso -vnc :99 -k de -cpu qemu32 -usb -usbdevice tablet + +VNC is only there for manual interaction with automated testruns. All automation goes over the monitor interface. +Moving+Clicking over VNC/SDL of course always worked. + +However, I found that even without -usbdevice tablet it will use absolute mouse with openSUSE. It mentions VMMOUSE in /var/log/Xorg.0.log + +I also noticed that when using VNC to move the mouse, the next mouse_button command will move to the last position set with mouse_move - not a problem for my needs, though. + +SDL on a headless server is not possible because of Bug #691424 + +Btw: test results can be seen on http://openqa.opensuse.org/results/ + +Bard, are you going to submit the patch for inclusion in qemu? + +Ah, there was a discussion where a better solution was supposed to be found. Maybe a new try is needed with the argumentation that it doesn't make the current code worse at all: +http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg00742.html + +Apart from the patch missing a Signed-off-by, I have doubts whether reusing the coordinates from the last monitor command is generally correct. It should rather be the current coordinates, whether set by monitor or via VNC/SDL, I guess. + +I think the right fix would be to remember the last position in ui/input.c, and use a new function kbd_mouse_button_event. mouse_move, followed by moving the mouse in the UI, followed by mouse_button 5 minutes later should not remember the position of the first mouse_move. + +Also, mouse_move should call dpy_mouse_set. + +Here's my attempt of fixing it: +http://lists.nongnu.org/archive/html/qemu-devel/2013-06/msg02506.html + +Triaging old bug tickets ... can you somehow still reproduce this problem with the latest version of QEMU (currently v2.9), or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/772275 b/results/classifier/zero-shot/108/none/772275 new file mode 100644 index 000000000..a856a56ad --- /dev/null +++ b/results/classifier/zero-shot/108/none/772275 @@ -0,0 +1,59 @@ +KVM: 0.520 +other: 0.502 +vnc: 0.495 +boot: 0.427 +debug: 0.402 +permissions: 0.381 +device: 0.373 +performance: 0.350 +PID: 0.337 +network: 0.315 +graphic: 0.301 +socket: 0.284 +semantic: 0.281 +files: 0.262 + +qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging + +Hi, + +I'm a proxmox distrib user, + +I have network error with virtio nic cards in win2008r2sp1 server, only with qemu 0.14 and 2.6.35 kernel combination. + +after some network transferts (can be 2mb or 500mb), nic doesn't respond anymore. only way is to reboot. + +e1000 driver working fine. + +revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 + 2.6.32 kernel is working fine too. + +i'm using virtio nic drivers 1.1.16 from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ + +i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26 + +i'm not the only proxmox user ,more users reports here : + +http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio-drivers-for-Windows-and-latest-PVE-1.8 + +i've also see that a slackware user with winxp guest has the same problem + +http://www.spinics.net/lists/kvm/msg51089.html + + +I can help to debug if it's possible to have logs somewhere ..... + +Forget to say: + +i'm using a quad-amd opteron 6172 (12cores) server, 256gb ram. + +kvm guest launch command: + +/usr/bin/kvm -monitor unix:/var/run/qemu-server/124.mon,server,nowait -vnc unix:/var/run/qemu-server/124.vnc,password -pidfile /var/run/qemu-server/124.pid -daemonize -usbdevice tablet -name testmachine -smp sockets=1,cores=12 -nodefaults -boot menu=on -tdf -localtime -rtc-td-hack -k fr -vga std -device lsi,id=scsi0,bus=pci.0,addr=0x5 -device lsi,id=scsi1,bus=pci.0,addr=0x6 -drive file=/dev/cdrom,if=none,id=drive-ide2,media=cdrom -device ide-drive,bus=ide.1,unit=0,drive=drive-ide2,id=disk-ide2 -drive file=/dev/disk/by-id/scsi-3600144f0f62f0e0000004d64fcaf000f,if=none,id=drive-virtio0,cache=none,boot=on -device virtio-blk-pci,drive=drive-virtio0,id=disk-virtio0,bus=pci.0,addr=0x7 -drive file=/dev/disk/by-id/scsi-3600144f0f62f0e0000004d6614f00012,if=none,id=drive-virtio1,cache=none -device virtio-blk-pci,drive=drive-virtio1,id=disk-virtio1,bus=pci.0,addr=0x8 -m 4000 -netdev type=tap,id=netdev2,ifname=tap124i101d2,script=/var/lib/qemu-server/bridge-vlan,vhost=on -device virtio-net-pci,mac=76:33:01:8E:91:B8,netdev=netdev2,id=nic2,bus=pci.0,addr=0x18 -netdev type=tap,id=netdev1,ifname=tap124i31d1,script=/var/lib/qemu-server/bridge-vlan,vhost=on -device virtio-net-pci,mac=02:A5:80:68:5E:EA,netdev=netdev1,id=nic1,bus=pci.0,addr=0x17 + + + + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU and the latest version of the virtio-net drivers? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/772358 b/results/classifier/zero-shot/108/none/772358 new file mode 100644 index 000000000..ef9fe7eb0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/772358 @@ -0,0 +1,42 @@ +device: 0.229 +network: 0.204 +graphic: 0.179 +vnc: 0.106 +semantic: 0.106 +performance: 0.091 +socket: 0.067 +other: 0.056 +KVM: 0.045 +permissions: 0.030 +boot: 0.028 +debug: 0.022 +PID: 0.020 +files: 0.016 + +VNC working depends on command line options order + +OS: Ubuntu 10.04.2, amd64 +Pkg version: 0.12.3+noroms-0ubuntu9.5 + +if -nographic option is specified before -vnc, vnc works, if vice-versa, it does not. I have been told (thanks, mjt), that -nographic is supposed to disable any graphic output, including vnc, so possibly it's a documentation bug: + +- kvm man page talks about -nographic disabling SDL , not VNC. While it might be the same to you, it was not to me and my colleagues + +- if -vnc and -nographic are conflicting, perhaps kvm should error out or at least warn + +- monitor console's message on "change vnc 127.0.0.1:1" command: "Could not start server on 127.0.0.1:1" is not helpful either + +- order of the options should not matter + +Example: (VNC works) + +/usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive if=virtio,file=/dev/vg0/kvm-ubuntu,boot=on,media=disk,cache=none,index=0 -net nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio -nographic -daemonize -vnc 127.0.0.1:1 -pidfile /var/run/kvm/1 + +Example: (VNC does not work, also confuses terminal): + +/usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive if=virtio,file=/dev/vg0/kvm-ubuntu,boot=on,media=disk,cache=none,index=0 -net nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio -vnc 127.0.0.1:1 -nographic -daemonize -pidfile /var/run/kvm/1 + +QEMU 0.12 is pretty much outdated nowadays ... can you still reproduce this problem with the latest version of QEMU, or can we close this bug? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/779151 b/results/classifier/zero-shot/108/none/779151 new file mode 100644 index 000000000..a8dc86b7d --- /dev/null +++ b/results/classifier/zero-shot/108/none/779151 @@ -0,0 +1,50 @@ +performance: 0.581 +device: 0.499 +debug: 0.478 +graphic: 0.466 +PID: 0.426 +permissions: 0.424 +vnc: 0.411 +files: 0.405 +other: 0.376 +semantic: 0.373 +network: 0.350 +boot: 0.315 +socket: 0.293 +KVM: 0.109 + +qemu-nbd crash during using with chroot + +I use qemu-nbd to mount my image. And after some times, qemu-nbd crashes and so the chroot freeze. + +ps aux | grep qemu : +root 2223 0.0 0.0 9776 548 ? Ss 18:03 0:00 qemu-nbd --connect=/dev/nbd0 /chroots/test/virtual.img +root 2224 0.0 0.0 10800 544 ? D 18:03 0:00 qemu-nbd --connect=/dev/nbd0 /chroots/test/virtual.img +root 2227 0.0 0.0 0 0 ? Z 18:03 0:00 [qemu-nbd] <defunct> +root 2357 0.0 0.0 5212 768 pts/0 D+ 18:07 0:00 grep qemu + +mount : +/dev/nbd0p1 on /chroots/test/amd64 type ext3 (rw,errors=remount-ro,commit=0) +/dev on /chroots/test/amd64/dev type devtmpfs (rw,mode=0755) +/dev/pts on /chroots/test/amd64/dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) +/proc on /chroots/test/amd64/proc type proc (rw) +/sys on /chroots/test/amd64/sys type sysfs (rw,noexec,nosuid,nodev) + + + +After reboot and mount the image, qemu-nbd crashes directly. + +Please provide some gdb backtrace from the failing qemu-nbd process, ie, show the root cause of the problem instead of showing multiple symptoms. + +Run qemu-nbd under gdb and when it crashes, run "bt" command. Before doing so, ensure you've debugging symbols for your qemu-nbd binary. + +And the most important part - what's the format of the image you're running qemu-nbd against, and what version of qemu-nbd you're using? + +Without all this, your bugreport is useless. + +Thanks. + +Ok i try to get the informations + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/789652 b/results/classifier/zero-shot/108/none/789652 new file mode 100644 index 000000000..02538e320 --- /dev/null +++ b/results/classifier/zero-shot/108/none/789652 @@ -0,0 +1,31 @@ +semantic: 0.154 +device: 0.107 +performance: 0.091 +graphic: 0.089 +network: 0.086 +other: 0.080 +socket: 0.076 +PID: 0.040 +vnc: 0.034 +KVM: 0.031 +boot: 0.023 +permissions: 0.020 +debug: 0.017 +files: 0.002 + +Cannot confirm email address on QEMU Wiki + +Cannot confirm email address on QEMU Wiki + +http://wiki.qemu.org/Special:ConfirmEmail + +--- + +Confirm e-mail address + +QEMU could not send your confirmation mail. Please check your e-mail address for invalid characters. + +Mailer returned: mailer error + +QEMU Wiki does not use e-mail addresses, so this is not a bug + diff --git a/results/classifier/zero-shot/108/none/790 b/results/classifier/zero-shot/108/none/790 new file mode 100644 index 000000000..e4823a2cd --- /dev/null +++ b/results/classifier/zero-shot/108/none/790 @@ -0,0 +1,16 @@ +performance: 0.560 +device: 0.529 +network: 0.502 +graphic: 0.485 +permissions: 0.304 +socket: 0.290 +boot: 0.266 +other: 0.254 +debug: 0.250 +PID: 0.187 +semantic: 0.172 +vnc: 0.144 +files: 0.128 +KVM: 0.069 + +Attribute bits in stage 1/stage 2 block descriptors are not fully masked during AArch64 page table walks diff --git a/results/classifier/zero-shot/108/none/792 b/results/classifier/zero-shot/108/none/792 new file mode 100644 index 000000000..17575a803 --- /dev/null +++ b/results/classifier/zero-shot/108/none/792 @@ -0,0 +1,16 @@ +device: 0.591 +debug: 0.513 +network: 0.262 +semantic: 0.205 +permissions: 0.200 +graphic: 0.192 +PID: 0.156 +boot: 0.147 +socket: 0.131 +performance: 0.123 +vnc: 0.112 +other: 0.107 +files: 0.087 +KVM: 0.002 + +Qemu's helper mechanism usage related issues diff --git a/results/classifier/zero-shot/108/none/802 b/results/classifier/zero-shot/108/none/802 new file mode 100644 index 000000000..16aa0ffe9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/802 @@ -0,0 +1,41 @@ +device: 0.598 +graphic: 0.554 +debug: 0.518 +network: 0.482 +performance: 0.428 +semantic: 0.388 +PID: 0.145 +boot: 0.130 +other: 0.126 +permissions: 0.124 +KVM: 0.119 +socket: 0.085 +vnc: 0.061 +files: 0.052 + +Devices created using '-device' JSON syntax don't emit DEVICE_DELETED when unplugged +Description of problem: +Run the following sequence: + +``` + $ ./qemu-system-x86_64 -qmp stdio \ + -device '{"driver": "virtio-mouse-pci", "id": "dev0"}' \ + -device virtio-mouse-pci,id=dev1 +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 6}, "package": "v6.2.0-105-g7494244ffc-dirty"}, "capabilities": ["oob"]}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "device_del", "arguments": { "id": "dev0"} } +{"return": {}} +{ "execute": "device_del", "arguments": { "id": "dev1"} } +{"return": {}} +{ "execute": "system_reset" } +{"return": {}} +{"timestamp": {"seconds": 1641385071, "microseconds": 120178}, "event": "RESET", "data": {"guest": false, "reason": "host-qmp-system-reset"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 121431}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev1/virtio-backend"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 121684}, "event": "DEVICE_DELETED", "data": {"device": "dev1", "path": "/machine/peripheral/dev1"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 122297}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev0/virtio-backend"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 198581}, "event": "RESET", "data": {"guest": true, "reason": "guest-reset"}} + + ``` + +Notice the lack of a "DEVICE_DELETED" event with path "/machine/peripheral/dev0" - the device created with JSON syntax diff --git a/results/classifier/zero-shot/108/none/817 b/results/classifier/zero-shot/108/none/817 new file mode 100644 index 000000000..b665c35b7 --- /dev/null +++ b/results/classifier/zero-shot/108/none/817 @@ -0,0 +1,16 @@ +performance: 0.514 +PID: 0.512 +device: 0.478 +semantic: 0.402 +network: 0.362 +graphic: 0.246 +debug: 0.196 +other: 0.164 +permissions: 0.163 +boot: 0.115 +socket: 0.076 +files: 0.059 +vnc: 0.048 +KVM: 0.045 + +linux-user: waitid leaves target siginfo uninitialized when info.si_pid is zero diff --git a/results/classifier/zero-shot/108/none/851 b/results/classifier/zero-shot/108/none/851 new file mode 100644 index 000000000..1ffd9bc39 --- /dev/null +++ b/results/classifier/zero-shot/108/none/851 @@ -0,0 +1,248 @@ +other: 0.382 +performance: 0.351 +graphic: 0.346 +KVM: 0.345 +device: 0.326 +permissions: 0.316 +PID: 0.311 +files: 0.294 +debug: 0.270 +semantic: 0.264 +boot: 0.260 +vnc: 0.241 +network: 0.231 +socket: 0.231 + +qemu-img create results in tsan warnings +Description of problem: +Running qemu-img w/ tsan enabled results in a bunch of data races reported: + +``` +Formatting 'delta.img', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=0 backing_file=base.img backing_fmt=raw lazy_refcounts=off refcount_bits=16 +================== +WARNING: ThreadSanitizer: data race (pid=217825) + Atomic write of size 8 at 0x7b4800000228 by main thread: + #0 __tsan_atomic64_exchange <null> (qemu-img+0xb6a55) + #1 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:151:5 (qemu-img+0x239931) + #2 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Previous read of size 8 at 0x7b4800000228 by thread T5 (mutexes: write M42): + #0 aio_bh_enqueue /usr/local/google/home/pefoley/qemu/build/../util/async.c:82:9 (qemu-img+0x239c4c) + #1 qemu_bh_schedule /usr/local/google/home/pefoley/qemu/build/../util/async.c:186:5 (qemu-img+0x239c4c) + #2 worker_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:113:9 (qemu-img+0x24fe7c) + #3 qemu_thread_start /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:556:9 (qemu-img+0x225960) + + Location is heap block of size 336 at 0x7b4800000180 allocated by main thread: + #0 calloc <null> (qemu-img+0x68ff9) + #1 g_malloc0 <null> (libglib-2.0.so.0+0x59e70) + #2 qemu_init_main_loop /usr/local/google/home/pefoley/qemu/build/../util/main-loop.c:169:24 (qemu-img+0x24bd47) + #3 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5397:5 (qemu-img+0xddcd7) + + Mutex M42 (0x7b3800000010) created at: + #0 pthread_mutex_init <null> (qemu-img+0x6bc0f) + #1 qemu_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:57:11 (qemu-img+0x223f69) + #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:306:5 (qemu-img+0x24f24d) + #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f24d) + #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4) + #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7) + #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7) + #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7) + #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #15 <null> <null> (libc.so.6+0x51a2f) + + Thread T5 'worker' (tid=217829, running) created by main thread at: + #0 pthread_create <null> (qemu-img+0x6a49d) + #1 qemu_thread_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:596:11 (qemu-img+0x225800) + #2 do_spawn_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:134:5 (qemu-img+0x24fac3) + #3 spawn_thread_bh_fn /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:142:5 (qemu-img+0x24fac3) + #4 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96) + #5 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96) + #6 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #7 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #8 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #9 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #10 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + +SUMMARY: ThreadSanitizer: data race (/usr/local/google/home/pefoley/qemu/build/qemu-img+0xb6a55) in __tsan_atomic64_exchange +================== +================== +WARNING: ThreadSanitizer: data race (pid=217825) + Write of size 4 at 0x7b1c000005f0 by thread T5 (mutexes: write M42): + #0 worker_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:101:20 (qemu-img+0x24fde3) + #1 qemu_thread_start /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:556:9 (qemu-img+0x225960) + + Previous read of size 4 at 0x7b1c000005f0 by main thread (mutexes: write M19): + #0 thread_pool_completion_bh /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:170:19 (qemu-img+0x24f7ae) + #1 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96) + #2 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96) + #3 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #4 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #5 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #6 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #7 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Location is heap block of size 104 at 0x7b1c000005b0 allocated by thread T4: + #0 malloc <null> (qemu-img+0x68e0d) + #1 g_malloc <null> (libglib-2.0.so.0+0x59e18) + #2 thread_pool_submit_aio /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:249:11 (qemu-img+0x24edc8) + #3 thread_pool_submit_co /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:287:5 (qemu-img+0x24f0fe) + #4 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2046:12 (qemu-img+0x1b5334) + #5 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b5334) + #6 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2562:14 (qemu-img+0x1b5334) + #7 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #8 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #9 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #10 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #11 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #12 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #13 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #14 <null> <null> (libc.so.6+0x51a2f) + + Mutex M42 (0x7b3800000010) created at: + #0 pthread_mutex_init <null> (qemu-img+0x6bc0f) + #1 qemu_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:57:11 (qemu-img+0x223f69) + #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:306:5 (qemu-img+0x24f24d) + #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f24d) + #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4) + #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7) + #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7) + #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7) + #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #15 <null> <null> (libc.so.6+0x51a2f) + + Mutex M19 (0x7b48000001e0) created at: + #0 pthread_mutex_init <null> (qemu-img+0x6bc0f) + #1 qemu_rec_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:120:11 (qemu-img+0x224625) + #2 aio_context_new /usr/local/google/home/pefoley/qemu/build/../util/async.c:555:5 (qemu-img+0x23a226) + #3 qemu_init_main_loop /usr/local/google/home/pefoley/qemu/build/../util/main-loop.c:169:24 (qemu-img+0x24bd47) + #4 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5397:5 (qemu-img+0xddcd7) + + Thread T5 'worker' (tid=217829, running) created by main thread at: + #0 pthread_create <null> (qemu-img+0x6a49d) + #1 qemu_thread_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:596:11 (qemu-img+0x225800) + #2 do_spawn_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:134:5 (qemu-img+0x24fac3) + #3 spawn_thread_bh_fn /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:142:5 (qemu-img+0x24fac3) + #4 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96) + #5 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96) + #6 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #7 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #8 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #9 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #10 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Thread T4 (tid=0, running) created by main thread at: + #0 on_new_fiber /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:90:25 (qemu-img+0x23cead) + #1 qemu_coroutine_new /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:219:5 (qemu-img+0x23cead) + #2 qemu_coroutine_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-coroutine.c:75:14 (qemu-img+0x24c7be) + #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:546:14 (qemu-img+0xf8884) + #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + +SUMMARY: ThreadSanitizer: data race /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:101:20 in worker_thread +================== +================== +WARNING: ThreadSanitizer: data race (pid=217825) + Atomic write of size 4 at 0x7b0c000000e8 by thread T5 (mutexes: write M42): + #0 __tsan_atomic32_fetch_or <null> (qemu-img+0xb9ec1) + #1 aio_bh_enqueue /usr/local/google/home/pefoley/qemu/build/../util/async.c:80:17 (qemu-img+0x239c23) + #2 qemu_bh_schedule /usr/local/google/home/pefoley/qemu/build/../util/async.c:186:5 (qemu-img+0x239c23) + #3 worker_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:113:9 (qemu-img+0x24fe7c) + #4 qemu_thread_start /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:556:9 (qemu-img+0x225960) + + Previous read of size 4 at 0x7b0c000000e8 by main thread: + #0 aio_compute_bh_timeout /usr/local/google/home/pefoley/qemu/build/../util/async.c:209:18 (qemu-img+0x239e7f) + #1 aio_compute_timeout /usr/local/google/home/pefoley/qemu/build/../util/async.c:232:15 (qemu-img+0x239e7f) + #2 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:624:26 (qemu-img+0x21f9c2) + #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Location is heap block of size 48 at 0x7b0c000000c0 allocated by thread T4: + #0 malloc <null> (qemu-img+0x68e0d) + #1 g_malloc <null> (libglib-2.0.so.0+0x59e18) + #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:305:27 (qemu-img+0x24f235) + #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f235) + #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4) + #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7) + #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7) + #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7) + #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #15 <null> <null> (libc.so.6+0x51a2f) + + Mutex M42 (0x7b3800000010) created at: + #0 pthread_mutex_init <null> (qemu-img+0x6bc0f) + #1 qemu_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:57:11 (qemu-img+0x223f69) + #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:306:5 (qemu-img+0x24f24d) + #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f24d) + #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4) + #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7) + #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7) + #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7) + #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #15 <null> <null> (libc.so.6+0x51a2f) + + Thread T5 'worker' (tid=217829, running) created by main thread at: + #0 pthread_create <null> (qemu-img+0x6a49d) + #1 qemu_thread_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:596:11 (qemu-img+0x225800) + #2 do_spawn_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:134:5 (qemu-img+0x24fac3) + #3 spawn_thread_bh_fn /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:142:5 (qemu-img+0x24fac3) + #4 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96) + #5 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96) + #6 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #7 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #8 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #9 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #10 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Thread T4 (tid=0, running) created by main thread at: + #0 on_new_fiber /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:90:25 (qemu-img+0x23cead) + #1 qemu_coroutine_new /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:219:5 (qemu-img+0x23cead) + #2 qemu_coroutine_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-coroutine.c:75:14 (qemu-img+0x24c7be) + #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:546:14 (qemu-img+0xf8884) + #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + +SUMMARY: ThreadSanitizer: data race (/usr/local/google/home/pefoley/qemu/build/qemu-img+0xb9ec1) in __tsan_atomic32_fetch_or +================== +ThreadSanitizer: reported 3 warnings +``` +Steps to reproduce: +1. ./configure --target-list=x86_64-softmmu --enable-tsan --cc=clang --cxx=clang++ +2. make -j12 +3. touch base.img +4. build/qemu-img create -b base.img -f qcow2 -F raw delta.img + +./configure --target-list=x86_64-softmmu --enable-tsan --cc=clang --cxx=clang++ +touch base.img +build/qemu-img create -b base.img -f qcow2 -F raw delta.img diff --git a/results/classifier/zero-shot/108/none/852 b/results/classifier/zero-shot/108/none/852 new file mode 100644 index 000000000..ed3717956 --- /dev/null +++ b/results/classifier/zero-shot/108/none/852 @@ -0,0 +1,46 @@ +device: 0.591 +performance: 0.553 +semantic: 0.431 +permissions: 0.377 +vnc: 0.370 +PID: 0.348 +socket: 0.318 +graphic: 0.307 +files: 0.288 +debug: 0.280 +network: 0.259 +other: 0.088 +boot: 0.083 +KVM: 0.042 + +ppc64le: possible SIMD issue casting double to int +Description of problem: +Working with numpy in a ppc64le VM, I ran into a strange double -to casting issue, specifically when casting an array of 1.0 values to 1 values. The numpy folks guided me to a small reproducible test case. + +The attached [convert.c](/uploads/2dd7936f4defccf816ffee7c7c002e77/convert.c) creates double and int arrays of length `1 <= n <= 16`. The double array is filled with the value 1.0, and both arrays are passed to a function that converts the value. + +With `-O2`, output is as expected (truncated here): + +``` +i = 1: 1 +i = 2: 1 1 +i = 3: 1 1 1 +i = 4: 1 1 1 1 +i = 5: 1 1 1 1 1 +i = 6: 1 1 1 1 1 1 +``` + +With `-O3`, all values that fit into blocks of four become zero: +``` +i = 1: 1 +i = 2: 1 1 +i = 3: 1 1 1 +i = 4: 0 0 0 0 +i = 5: 0 0 0 0 1 +i = 6: 0 0 0 0 1 1 +``` + +I tested this with executables compiled on a physical ppc64le host, where the issue is not reproducible. +Steps to reproduce: +1. `gcc -O2 -o convert convert.c && ./convert` +2. `gcc -O3 -o convert convert.c && ./convert` diff --git a/results/classifier/zero-shot/108/none/856 b/results/classifier/zero-shot/108/none/856 new file mode 100644 index 000000000..deb16b34c --- /dev/null +++ b/results/classifier/zero-shot/108/none/856 @@ -0,0 +1,76 @@ +other: 0.498 +semantic: 0.434 +performance: 0.412 +permissions: 0.389 +graphic: 0.386 +debug: 0.369 +PID: 0.360 +KVM: 0.354 +device: 0.351 +vnc: 0.338 +boot: 0.326 +network: 0.314 +socket: 0.314 +files: 0.271 + +Occasional deadlock in linux-user (sh4) when running threadcount test +Description of problem: + +Steps to reproduce: +1. docker run --rm -it -u (id -u) -v $HOME:$HOME -w (pwd) qemu/debian-all-test-cross /bin/bash +2. '../../configure' '--cc=clang' '--cxx=clang++' '--disable-system' '--target-list-exclude=microblazeel-linux-user,aarch64_be-linux-user,i386-linux-user,m68k-linux-user,mipsn32el-linux-user,xtensaeb-linux-user' '--extra-cflags=-fsanitize=undefined' '--extra-cflags=-fno-sanitize-recover=undefined' +3. make; make build-tcg +4. retry.py -n 400 -c -- timeout --foreground 90 ./qemu-sh4 -plugin ./tests/plugin/libinsn.so -d plugin ./tests/tcg/sh4-linux-user/threadcount + +Failure rate on hackbox: + +``` +Results summary: +0: 397 times (99.25%), avg time 0.686 (0.00 varience/0.01 deviation) +124: 3 times (0.75%), avg time 90.559 (0.00 varience/0.01 deviation) +``` + +It seems to fail more frequently on Gitlabs CI +Additional information: +Without the timeout you end up with a deadlock. The following backtrace was found, stepping in gdb unwedges the hang: + +``` +(gdb) info threads + Id Target Id Frame +* 1 LWP 15894 "qemu-sh4" safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 + 2 LWP 15994 "qemu-sh4" 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6 + 3 LWP 15997 "qemu-sh4" safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +(gdb) bt +#0 safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x0000560ee17196e4 in safe_futex (uaddr=0x58e8, op=-513652411, val=<optimized out>, timeout=0xf0, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:681 +#2 do_safe_futex (uaddr=0x58e8, op=-513652411, val=<optimized out>, timeout=0xf0, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:7757 +#3 0x0000560ee170c8d9 in do_syscall1 (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=22760, arg4=<optimized out>, arg5=<optimized out>, arg6=240, arg7=0, arg8=0) at /home/alex.bennee/lsrc/qemu.git/include/exec/cpu_ldst.h:90 +#4 0x0000560ee170220c in do_syscall (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=<optimized out>, arg6=<optimized out>, arg7=<optimized out>, arg8=<optimized out>) at ../../linux-user/syscall.c:13239 +#5 0x0000560ee1626111 in cpu_loop (env=0x560ee294b028) at ../../linux-user/sh4/cpu_loop.c:43 +#6 0x0000560ee16ee37d in main (argc=-493657104, argv=0x7ffdcaf52028, envp=<optimized out>) at ../../linux-user/main.c:883 +(gdb) thread 2 +[Switching to thread 2 (LWP 15994)] +#0 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6 +(gdb) bt +#0 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6 +#1 0x0000560ee1847bd6 in qemu_futex_wait (f=<optimized out>, val=<optimized out>) at /home/alex.bennee/lsrc/qemu.git/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=0x560ee2738974 <rcu_call_ready_event>) at ../../util/qemu-thread-posix.c:481 +#3 0x0000560ee18539a2 in call_rcu_thread (opaque=<optimized out>) at ../../util/rcu.c:261 +#4 0x0000560ee1847f17 in qemu_thread_start (args=0x560ee2933eb0) at ../../util/qemu-thread-posix.c:556 +#5 0x00007f956b8f6fa3 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0 +#6 0x00007f956b8064cf in clone () from target:/lib/x86_64-linux-gnu/libc.so.6 +(gdb) thread 3 +[Switching to thread 3 (LWP 15997)] +#0 safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +75 cmp $-4095, %rax +(gdb) bt +#0 safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x0000560ee17196e4 in safe_futex (uaddr=0x2, op=-513652411, val=<optimized out>, timeout=0x3f7fcdc4, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:681 +#2 do_safe_futex (uaddr=0x2, op=-513652411, val=<optimized out>, timeout=0x3f7fcdc4, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:7757 +#3 0x0000560ee170c8d9 in do_syscall1 (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=2, arg4=<optimized out>, arg5=<optimized out>, arg6=1065340356, arg7=0, arg8=0) at /home/alex.bennee/lsrc/qemu.git/include/exec/cpu_ldst.h:90 +#4 0x0000560ee170220c in do_syscall (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=<optimized out>, arg6=<optimized out>, arg7=<optimized out>, arg8=<optimized out>) at ../../linux-user/syscall.c:13239 +#5 0x0000560ee1626111 in cpu_loop (env=0x560ee2a2c2d8) at ../../linux-user/sh4/cpu_loop.c:43 +#6 0x0000560ee171728f in clone_func (arg=<optimized out>) at ../../linux-user/syscall.c:6608 +#7 0x00007f956b8f6fa3 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0 +#8 0x00007f956b8064cf in clone () from target:/lib/x86_64-linux-gnu/libc.so.6 +``` diff --git a/results/classifier/zero-shot/108/none/902720 b/results/classifier/zero-shot/108/none/902720 new file mode 100644 index 000000000..1faba75a9 --- /dev/null +++ b/results/classifier/zero-shot/108/none/902720 @@ -0,0 +1,131 @@ +KVM: 0.364 +permissions: 0.352 +other: 0.349 +graphic: 0.340 +performance: 0.337 +semantic: 0.332 +PID: 0.318 +network: 0.315 +debug: 0.304 +device: 0.274 +vnc: 0.270 +boot: 0.261 +files: 0.241 +socket: 0.216 + +TIME_MAX not set correctly for OpenBSD in qemu-common.h + +Looking at the OpenBSD buildbot logs I noticed a warning that appears to be a bug in the code. +OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and 64-bit). + + CC i386-softmmu/monitor.o +/buildbot-qemu/default_openbsd_current/build/monitor.c: In function 'expire_password': +/buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning: overflow in implicit constant conversion + +qemu-common.h has... + +#ifndef TIME_MAX +#define TIME_MAX LONG_MAX +#endif + +for OpenBSD this should be INT_MAX. + +On 11/12/11 5:53 AM, Stefan Weil wrote: +> Am 11.12.2011 07:47, schrieb Brad Smith: +>> Public bug reported: +>> +>> Looking at the OpenBSD buildbot logs I noticed a warning that appears +>> to be a bug in the code. +>> OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and +>> 64-bit). +>> +>> CC i386-softmmu/monitor.o +>> /buildbot-qemu/default_openbsd_current/build/monitor.c: In function +>> 'expire_password': +>> /buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning: +>> overflow in implicit constant conversion +>> +>> qemu-common.h has... +>> +>> #ifndef TIME_MAX +>> #define TIME_MAX LONG_MAX +>> #endif +>> +>> for OpenBSD this should be INT_MAX. +>> +>> ** Affects: qemu +>> Importance: Undecided +>> Status: New +> +> This needs special handling for w32 / w64, too. +> Looking at the code where TIME_MAX is used, I assume that +> more fixes are needed. The following code for example +> won't work: +> +> if (lifetime > INT_MAX) { +> +> What about using +> +> #define TIME_FOREVER -1 +> +> instead of TIME_MAX? Of course this would need additional +> code changes. +> +> Regards, +> Stefan Weil + +Gerd? + +Still looking for comment on this since you added the initial code which +has this bug in it. + +-- +This message has been scanned for viruses and +dangerous content by MailScanner, and is +believed to be clean. + + + + Hi, + +>>> Looking at the OpenBSD buildbot logs I noticed a warning that appears +>>> to be a bug in the code. +>>> OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and +>>> 64-bit). + +Ouch. Adding 64bit arch with 32bit time_t is pretty lame IMHO. There +are a bunch of years left to fix that that though. + +>>> #ifndef TIME_MAX +>>> #define TIME_MAX LONG_MAX +>>> #endif +>>> +>>> for OpenBSD this should be INT_MAX. + +Guess we'll need an #ifdef then. + +>> This needs special handling for w32 / w64, too. +>> Looking at the code where TIME_MAX is used, I assume that +>> more fixes are needed. The following code for example +>> won't work: +>> +>> if (lifetime > INT_MAX) { + +With 32bit time_t lifetime wouldn't become larger than INT_MAX anyway, +so it doesn't matter ;) + +> Still looking for comment on this since you added the initial code which +> has this bug in it. + +cheers, + Gerd + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +Since this bug report was filed OpenBSD has switched from 32-bit time_t to 64-bit time_t on all archs (yes, including 32-bit archs like i386, arm, powerpc). So instead of INT_MAX TIME_MAX should now be set to LLONG_MAX. + +This was fixed in commit e7b47c22e2df14d, which was in the 2.11.0 release. + + diff --git a/results/classifier/zero-shot/108/none/908 b/results/classifier/zero-shot/108/none/908 new file mode 100644 index 000000000..4e13d6313 --- /dev/null +++ b/results/classifier/zero-shot/108/none/908 @@ -0,0 +1,16 @@ +semantic: 0.560 +device: 0.369 +graphic: 0.365 +network: 0.231 +debug: 0.209 +performance: 0.191 +other: 0.153 +permissions: 0.107 +vnc: 0.099 +PID: 0.082 +KVM: 0.055 +boot: 0.035 +files: 0.027 +socket: 0.014 + +since when is qemu-guest-agent included in the qemu package ? diff --git a/results/classifier/zero-shot/108/none/912983 b/results/classifier/zero-shot/108/none/912983 new file mode 100644 index 000000000..d026d1740 --- /dev/null +++ b/results/classifier/zero-shot/108/none/912983 @@ -0,0 +1,64 @@ +device: 0.240 +semantic: 0.216 +performance: 0.214 +PID: 0.205 +graphic: 0.196 +socket: 0.140 +boot: 0.109 +vnc: 0.098 +network: 0.091 +permissions: 0.073 +files: 0.069 +other: 0.064 +KVM: 0.060 +debug: 0.050 + +Unable to install OS/2 Warp v3 past disk 2 + +To whom it may concern, + +As you may (or may not) be aware, QEMU is currently unable to readily install OS/2 Warp v3 (OS2W3) when asked for Installation Diskette 2 (http://www.claunia.com/qemu/objectManager.php?sClass=version&iId=132&iTestingId=138). + +QEMU 0.8.2 is the last known (to me) release to successfully install OS2W3. QEMU version 1.0 and the latest development version (as of 2012-01-05) have been verified not to work. + +A 'git bisect' reveals the issue was introduced during a migration to new removable media handling prior to the QEMU 0.9.0 release: + + There are only 'skip'ped commits left to test. + The first bad commit could be any of: + 66c6ef7678939f2119eb649074babf5d5b2666f6 + ea185bbda732dae6b6a5a44699f90c83e21f1494 + 19cb37389f4641d48803f0c5d72708749cbcf318 + We cannot bisect more! + +For testing, the 'qcow' hard drive format was chosen due to QEMU 0.8.2 not having 'qcow2': + + $ qemu -M isapc -m 8 -localtime -soundhw sb16 -hda os2.qcow -fda install.img -boot a + +Of note, the ISA-only PC (isapc) was needed for QEMU 0.8.2 to 0.9.0. Otherwise QEMU hangs on start-up. Later versions of QEMU, segmentation fault when attempting to use '-M isapc' though boot correctly when using the default PC machine. + + +The currently preferred method to install OS2W3 is to use another application (such as VirtualBox or VMWare), using a QEMU compatible disk image format. Once installed, QEMU can then run OS2W3; which it does phenomenally well. + +However, I've identified a way to install OS2W3 exclusively with QEMU, which may also shed additional light on the issue. + +1. Using a relatively new QEMU (I'm on 0.11.1), install OS2W3 as you normally would on to a 'qcow2' hard drive. +2. When Installation Diskette 2 is reached, save a VM snapshot. +3. Quit QEMU and re-run, loading the VM state *with* the Installation Diskette 2 image in the floppy drive. + $ qemu -m 8 -localtime -soundhw sb16 -hda os2.qcow2 -fda disk2.img -loadvm install +The installation process will then continue as normal. + +This same method can be used once OS2W3 continues installing from it's GUI. Installation Diskette 7 experiences the same issue of not being recognised when inserted. + +Of note, as an unrelated issue, I was unable to save VM snapshots in QEMU 1.0 or later. + + +Thank you for a fantastic emulator. + + +cheers, +multitude + +Triaging old bug tickets ... 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/zero-shot/108/none/920772 b/results/classifier/zero-shot/108/none/920772 new file mode 100644 index 000000000..7331ad09e --- /dev/null +++ b/results/classifier/zero-shot/108/none/920772 @@ -0,0 +1,57 @@ +KVM: 0.529 +device: 0.418 +semantic: 0.361 +graphic: 0.316 +other: 0.311 +performance: 0.195 +boot: 0.169 +socket: 0.126 +PID: 0.112 +network: 0.091 +permissions: 0.083 +files: 0.069 +vnc: 0.067 +debug: 0.055 + +Win98SE glitches RHEL6.2/CentOS6.2 QEMU + +I'm not sure if this is something anyone will be interested in, +but I ran into some glitches setting up a Windows 98 SE +QEMU VM with a relatively recent version. Needed this +to restore an ancient backup and got it working well +enough to get the job done. + +Versions +======== + +Distro: CentOS 6.2 + +Kernel: upstream 3.1.8 + +QEMU: +gpxe-roms-qemu-0.9.7-6.9.el6.noarch +qemu-img-0.12.1.2-2.209.el6_2.1.x86_64 +qemu-kvm-0.12.1.2-2.209.el6_2.1.x86_64 + +Glitches: + +1) Doesn't work in KVM mode, screen goes black +just after installer is finishing up and switching to +Win98. Saw this issue has been around for awhile. + +2) Got it working in QEMU mode, but BIOS plug-n-play +driver fails. This prevents other devices from working. + +a) CDROM not recognized + +b) Realtek 8139C driver (installed separately after +Win98) not recognized. + +I don't need these issues fixed, just reporting the +in case it's of interest and/or helpful. Can provide +more detail on request. + +QEMU 0.12 is pretty much outdated nowadays - can you still reproduce these issues with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/none/926 b/results/classifier/zero-shot/108/none/926 new file mode 100644 index 000000000..1abe6f8a3 --- /dev/null +++ b/results/classifier/zero-shot/108/none/926 @@ -0,0 +1,16 @@ +device: 0.599 +network: 0.538 +vnc: 0.469 +socket: 0.361 +PID: 0.330 +boot: 0.248 +graphic: 0.241 +semantic: 0.237 +debug: 0.116 +other: 0.108 +files: 0.067 +permissions: 0.055 +performance: 0.054 +KVM: 0.010 + +block-backend assertion with Cocoa UI diff --git a/results/classifier/zero-shot/108/none/942659 b/results/classifier/zero-shot/108/none/942659 new file mode 100644 index 000000000..34fbd7404 --- /dev/null +++ b/results/classifier/zero-shot/108/none/942659 @@ -0,0 +1,63 @@ +semantic: 0.575 +other: 0.443 +device: 0.294 +socket: 0.171 +PID: 0.143 +graphic: 0.124 +performance: 0.116 +permissions: 0.095 +debug: 0.087 +vnc: 0.080 +network: 0.065 +files: 0.064 +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/zero-shot/108/none/947273 b/results/classifier/zero-shot/108/none/947273 new file mode 100644 index 000000000..f6a6dba79 --- /dev/null +++ b/results/classifier/zero-shot/108/none/947273 @@ -0,0 +1,23 @@ +graphic: 0.427 +semantic: 0.236 +device: 0.154 +other: 0.129 +vnc: 0.074 +network: 0.056 +performance: 0.050 +permissions: 0.042 +boot: 0.031 +debug: 0.019 +socket: 0.013 +files: 0.009 +PID: 0.007 +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/zero-shot/108/none/950 b/results/classifier/zero-shot/108/none/950 new file mode 100644 index 000000000..322a155d6 --- /dev/null +++ b/results/classifier/zero-shot/108/none/950 @@ -0,0 +1,38 @@ +vnc: 0.474 +KVM: 0.417 +device: 0.269 +debug: 0.266 +PID: 0.264 +graphic: 0.263 +network: 0.250 +performance: 0.203 +permissions: 0.191 +other: 0.184 +boot: 0.160 +socket: 0.156 +files: 0.137 +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/zero-shot/108/none/954 b/results/classifier/zero-shot/108/none/954 new file mode 100644 index 000000000..e851ca3a0 --- /dev/null +++ b/results/classifier/zero-shot/108/none/954 @@ -0,0 +1,1272 @@ +KVM: 0.199 +graphic: 0.154 +permissions: 0.147 +other: 0.115 +vnc: 0.114 +debug: 0.105 +semantic: 0.098 +PID: 0.097 +performance: 0.083 +socket: 0.082 +device: 0.081 +boot: 0.071 +network: 0.063 +files: 0.046 + +qemu 6.2.0 with SEV in x86_64 initrd unpack ? +Description of problem: +The guest kernel panic from qemu 6.2.0, works fine on 6.0.0 and 6.1.0, works fine without SEV on 6.2.0 too. + +From our research it seems that initrd is not unpacked and initialized in an SEV context on 6.2.0 as we can see in logs without SEV that the initrd is well unpacked. Please have a look on additional informations for all the logs. + +We can see this crash during guest initialization: +``` +[ 0.252891] VFS: Cannot open root device \(null)\ or unknown-block(0,0): error -6 +[ 0.253054] Please append a correct \root=\ boot option; here are the available partitions: +[ 0.253179] 0100 4096 ram0 +[ 0.253181] (driver?) +[ 0.253285] 0101 4096 ram1 +[ 0.253286] (driver?) +[ 0.253389] 0102 4096 ram2 +[ 0.253390] (driver?) +[ 0.253490] 0103 4096 ram3 +[ 0.253491] (driver?) +[ 0.253595] 0104 4096 ram4 +[ 0.253596] (driver?) +[ 0.253708] 0105 4096 ram5 +[ 0.253709] (driver?) +[ 0.253816] 0106 4096 ram6 +[ 0.253817] (driver?) +[ 0.253965] 0107 4096 ram7 +[ 0.253967] (driver?) +[ 0.254065] 0108 4096 ram8 +[ 0.254066] (driver?) +[ 0.254170] 0109 4096 ram9 +[ 0.254171] (driver?) +[ 0.254274] 010a 4096 ram10 +[ 0.254276] (driver?) +[ 0.254392] 010b 4096 ram11 +[ 0.254393] (driver?) +[ 0.254514] 010c 4096 ram12 +[ 0.254516] (driver?) +[ 0.254639] 010d 4096 ram13 +[ 0.254640] (driver?) +[ 0.254755] 010e 4096 ram14 +[ 0.254756] (driver?) +[ 0.254871] 010f 4096 ram15 +[ 0.254872] (driver?) +[ 0.254996] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) +[ 0.255115] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.31 #1 +[ 0.255215] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.255339] Call Trace: +[ 0.255387] <TASK> +[ 0.255430] dump_stack_lvl+0x34/0x44 +[ 0.255499] panic+0xe8/0x27a +[ 0.255563] mount_block_root+0x16b/0x1fe +[ 0.255631] ? rest_init+0xc0/0xc0 +[ 0.255692] prepare_namespace+0x131/0x160 +[ 0.255757] ? rest_init+0xc0/0xc0 +[ 0.255823] kernel_init+0x11/0x100 +[ 0.255889] ret_from_fork+0x22/0x30 +[ 0.255969] </TASK> +[ 0.256061] Kernel Offset: disabled +[ 0.256130] Rebooting in 1 seconds.. +``` +Steps to reproduce: +1. build kernel with right config (build_kernel from kata-containers) with sev support (-x sev) & get kata-containers initrd +2. Launch the command on a AMD SEV compatible device + +This is a complex problem I guess I can provide more informations if needed. +Additional information: +We didn't see any logs from QEMU when running this command line even when putting -D file... + +Complete output from QEMU 6.2.0 with SEV : +``` +[ 0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021 +[ 0.000000] Command line: 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 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] efi: EFI v2.70 by EDK II +[ 0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e9d8118 +[ 0.000000] SMBIOS 2.8 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.000000] Hypervisor detected: KVM +[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00 +[ 0.000000] kvm-clock: cpu 0, msr 3d401001, primary cpu clock +[ 0.000000] kvm-clock: using sched offset of 4061892066 cycles +[ 0.000003] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns +[ 0.000006] tsc: Detected 2994.372 MHz processor +[ 0.000159] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000162] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000169] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000 +[ 0.000215] MTRR default type: write-back +[ 0.000216] MTRR fixed ranges enabled: +[ 0.000218] 00000-9FFFF write-back +[ 0.000219] A0000-FFFFF uncachable +[ 0.000220] MTRR variable ranges enabled: +[ 0.000222] 0 base 0000C0000000 mask FFFFC0000000 uncachable +[ 0.000224] 1 base 0000B0000000 mask FFFFF0000000 uncachable +[ 0.000225] 2 base 001000000000 mask FFF800000000 uncachable +[ 0.000226] 3 disabled +[ 0.000227] 4 disabled +[ 0.000228] 5 disabled +[ 0.000229] 6 disabled +[ 0.000229] 7 disabled +[ 0.000277] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.008747] Using GB pages for direct mapping +[ 0.009448] Secure boot could not be determined +[ 0.009466] ACPI: Early table checksum verification disabled +[ 0.009476] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS ) +[ 0.009482] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS BXPC 00000001 01000013) +[ 0.009490] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009497] ACPI: DSDT 0x000000007F979000 003EAE (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009502] ACPI: FACS 0x000000007F9DD000 000040 +[ 0.009506] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009510] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009515] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009519] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009523] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009532] ACPI: Local APIC address 0xfee00000 +[ 0.009575] Zone ranges: +[ 0.009576] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.009578] DMA32 [mem 0x0000000001000000-0x000000007fe5ffff] +[ 0.009580] Normal empty +[ 0.009581] Device empty +[ 0.009582] Movable zone start for each node +[ 0.009583] Early memory node ranges +[ 0.009585] node 0: [mem 0x0000000000001000-0x000000000009ffff] +[ 0.009587] node 0: [mem 0x0000000000100000-0x00000000007fffff] +[ 0.009588] node 0: [mem 0x0000000000808000-0x000000000080ffff] +[ 0.009589] node 0: [mem 0x0000000000900000-0x000000007f6eefff] +[ 0.009590] node 0: [mem 0x000000007f9ff000-0x000000007fe5ffff] +[ 0.009592] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff] +[ 0.009595] On node 0 totalpages: 522743 +[ 0.009596] DMA zone: 59 pages used for memmap +[ 0.009597] DMA zone: 1814 pages reserved +[ 0.009599] DMA zone: 3751 pages, LIFO batch:0 +[ 0.009931] DMA zone: 29017 pages in unavailable ranges +[ 0.009933] DMA32 zone: 8122 pages used for memmap +[ 0.009934] DMA32 zone: 518992 pages, LIFO batch:63 +[ 0.014254] DMA32 zone: 1200 pages in unavailable ranges +[ 0.014984] ACPI: PM-Timer IO Port: 0x608 +[ 0.014988] ACPI: Local APIC address 0xfee00000 +[ 0.015002] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.015201] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 +[ 0.015205] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.015207] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.015209] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.015210] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.015212] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.015213] ACPI: IRQ0 used by override. +[ 0.015214] ACPI: IRQ5 used by override. +[ 0.015216] ACPI: IRQ9 used by override. +[ 0.015217] ACPI: IRQ10 used by override. +[ 0.015217] ACPI: IRQ11 used by override. +[ 0.015220] Using ACPI (MADT) for SMP configuration information +[ 0.015223] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.015228] TSC deadline timer available +[ 0.015233] smpboot: Allowing 32 CPUs, 31 hotplug CPUs +[ 0.015245] kvm-guest: KVM setup pv remote TLB flush +[ 0.015254] kvm-guest: setup PV sched yield +[ 0.015272] [mem 0xc0000000-0xffffffff] available for PCI devices +[ 0.015274] Booting paravirtualized kernel on KVM +[ 0.015278] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns +[ 0.020479] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1 +[ 0.021723] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144 +[ 0.021732] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152 +[ 0.021734] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15 +[ 0.021744] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31 +[ 0.027310] kvm-guest: KVM setup async PF for cpu 0 +[ 0.027318] kvm-guest: stealtime: cpu 0, msr 7d622080 +[ 0.027332] Built 1 zonelists, mobility grouping on. Total pages: 512748 +[ 0.027335] Kernel command line: 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 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.027480] printk: log_buf_len individual max cpu contribution: 4096 bytes +[ 0.027481] printk: log_buf_len total cpu_extra contributions: 126976 bytes +[ 0.027483] printk: log_buf_len min size: 131072 bytes +[ 0.027731] printk: log_buf_len: 262144 bytes +[ 0.027733] printk: early log buf free: 123344(94%) +[ 0.027942] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) +[ 0.028047] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.028190] mem auto-init: stack:off, heap alloc:off, heap free:off +[ 0.041061] Memory: 1815804K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 274912K reserved, 0K cma-reserved) +[ 0.041173] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1 +[ 0.041309] rcu: Hierarchical RCU implementation. +[ 0.041311] rcu: RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32. +[ 0.041312] All grace periods are expedited (rcu_expedited). +[ 0.041313] Tracing variant of Tasks RCU enabled. +[ 0.041315] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. +[ 0.041316] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32 +[ 0.041372] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16 +[ 0.041910] rcu: Offload RCU callbacks from CPUs: (none). +[ 0.042080] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0 +[ 0.042159] Console: colour dummy device 80x25 +[ 0.162231] printk: console [ttyS0] enabled +[ 0.175286] AMD Memory Encryption Features active: SEV +[ 0.176044] ACPI: Core revision 20200925 +[ 0.176768] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.178070] APIC: Switch to symmetric I/O mode setup +[ 0.180011] x2apic enabled +[ 0.182376] Switched APIC routing to physical x2apic. +[ 0.183044] kvm-guest: setup PV IPIs +[ 0.189694] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.190655] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 0.191992] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488) +[ 0.193096] pid_max: default: 32768 minimum: 301 +[ 0.224045] LSM: Security Framework initializing +[ 0.225340] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.226368] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.227912] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.228021] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.228758] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.229578] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.230655] Spectre V2 : Mitigation: Full AMD retpoline +[ 0.231993] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.233038] Spectre V2 : Enabling Restricted Speculation for firmware calls +[ 0.234868] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.235997] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp +[ 0.237657] Freeing SMP alternatives memory: 28K +[ 0.238528] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0) +[ 0.239991] Performance Events: Fam17h+ core perfctr, AMD PMU driver. +[ 0.239991] ... version: 0 +[ 0.239991] ... bit width: 48 +[ 0.239991] ... generic registers: 6 +[ 0.239997] ... value mask: 0000ffffffffffff +[ 0.240552] ... max period: 00007fffffffffff +[ 0.241107] ... fixed-purpose events: 0 +[ 0.241610] ... event mask: 000000000000003f +[ 0.242405] rcu: Hierarchical SRCU implementation. +[ 0.243319] smp: Bringing up secondary CPUs ... +[ 0.243787] smp: Brought up 1 node, 1 CPU +[ 0.244000] smpboot: Max logical packages: 32 +[ 0.244475] smpboot: Total of 1 processors activated (5988.74 BogoMIPS) +[ 0.245487] devtmpfs: initialized +[ 0.245852] x86/mm: Memory block size: 128MB +[ 0.246502] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +[ 0.247472] futex hash table entries: 8192 (order: 7, 524288 bytes, linear) +[ 0.248308] NET: Registered protocol family 16 +[ 0.249031] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations +[ 0.250111] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations +[ 0.251331] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations +[ 0.252043] thermal_sys: Registered thermal governor 'step_wise' +[ 0.252048] cpuidle: using governor menu +[ 0.253569] ACPI: bus type PCI registered +[ 0.253974] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 0.254656] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 0.255546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 0.256020] PCI: Using configuration type 1 for base access +[ 0.257219] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages +[ 0.257889] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.258633] ACPI: Added _OSI(Module Device) +[ 0.259073] ACPI: Added _OSI(Processor Device) +[ 0.259531] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.259999] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.260534] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.260979] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.261508] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.263748] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 0.264963] ACPI: Interpreter enabled +[ 0.265375] ACPI: (supports S0 S5) +[ 0.265743] ACPI: Using IOAPIC for interrupt routing +[ 0.266290] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.267390] ACPI: Enabled 3 GPEs in block 00 to 3F +[ 0.272364] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 0.273025] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] +[ 0.274136] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR] +[ 0.275108] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME PCIeCapability] +[ 0.276009] PCI host bridge to bus 0000:00 +[ 0.276413] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.277047] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.277707] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.278440] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 0.279154] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 0.279885] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window] +[ 0.279995] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.280579] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 0.281678] pci 0000:00:01.0: [1af4:1043] type 00 class 0x078000 +[ 0.283998] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff] +[ 0.287128] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref] +[ 0.288918] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400 +[ 0.294626] pci 0000:00:03.0: [1af4:1048] type 00 class 0x010000 +[ 0.296349] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff] +[ 0.299044] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref] +[ 0.300892] pci 0000:00:04.0: [1af4:1044] type 00 class 0x00ff00 +[ 0.303526] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref] +[ 0.304902] pci 0000:00:05.0: [1af4:1049] type 00 class 0x000200 +[ 0.306875] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff] +[ 0.309436] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref] +[ 0.311525] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100 +[ 0.312373] pci 0000:00:1f.0: quirk: [io 0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO +[ 0.314653] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601 +[ 0.318160] pci 0000:00:1f.2: reg 0x20: [io 0x6040-0x605f] +[ 0.319336] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff] +[ 0.320607] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500 +[ 0.323429] pci 0000:00:1f.3: reg 0x20: [io 0x6000-0x603f] +[ 0.325167] pci_bus 0000:01: extended config space not accessible +[ 0.325943] acpiphp: Slot [0] registered +[ 0.326344] acpiphp: Slot [1] registered +[ 0.326753] acpiphp: Slot [2] registered +[ 0.327153] acpiphp: Slot [3] registered +[ 0.327557] acpiphp: Slot [4] registered +[ 0.327962] acpiphp: Slot [5] registered +[ 0.328009] acpiphp: Slot [6] registered +[ 0.328416] acpiphp: Slot [7] registered +[ 0.328817] acpiphp: Slot [8] registered +[ 0.329218] acpiphp: Slot [9] registered +[ 0.329625] acpiphp: Slot [10] registered +[ 0.330033] acpiphp: Slot [11] registered +[ 0.330448] acpiphp: Slot [12] registered +[ 0.330854] acpiphp: Slot [13] registered +[ 0.331261] acpiphp: Slot [14] registered +[ 0.331675] acpiphp: Slot [15] registered +[ 0.332008] acpiphp: Slot [16] registered +[ 0.332419] acpiphp: Slot [17] registered +[ 0.332827] acpiphp: Slot [18] registered +[ 0.333234] acpiphp: Slot [19] registered +[ 0.333647] acpiphp: Slot [20] registered +[ 0.334055] acpiphp: Slot [21] registered +[ 0.334468] acpiphp: Slot [22] registered +[ 0.334886] acpiphp: Slot [23] registered +[ 0.335298] acpiphp: Slot [24] registered +[ 0.335702] acpiphp: Slot [25] registered +[ 0.336008] acpiphp: Slot [26] registered +[ 0.336420] acpiphp: Slot [27] registered +[ 0.336824] acpiphp: Slot [28] registered +[ 0.337232] acpiphp: Slot [29] registered +[ 0.337636] acpiphp: Slot [30] registered +[ 0.338041] acpiphp: Slot [31] registered +[ 0.338650] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.339776] pci_bus 0000:00: on NUMA node 0 +[ 0.340242] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) +[ 0.340849] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) +[ 0.341462] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) +[ 0.342076] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) +[ 0.342685] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) +[ 0.343300] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) +[ 0.343918] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) +[ 0.344059] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) +[ 0.344636] ACPI: PCI Interrupt Link [GSIA] (IRQs *16) +[ 0.345142] ACPI: PCI Interrupt Link [GSIB] (IRQs *17) +[ 0.345660] ACPI: PCI Interrupt Link [GSIC] (IRQs *18) +[ 0.346245] ACPI: PCI Interrupt Link [GSID] (IRQs *19) +[ 0.346799] ACPI: PCI Interrupt Link [GSIE] (IRQs *20) +[ 0.347365] ACPI: PCI Interrupt Link [GSIF] (IRQs *21) +[ 0.347889] ACPI: PCI Interrupt Link [GSIG] (IRQs *22) +[ 0.348004] ACPI: PCI Interrupt Link [GSIH] (IRQs *23) +[ 0.349647] iommu: Default domain type: Translated +[ 0.350207] vgaarb: loaded +[ 0.350578] SCSI subsystem initialized +[ 0.350959] pps_core: LinuxPPS API ver. 1 registered +[ 0.351500] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 0.352007] PTP clock support registered +[ 0.352415] Registered efivars operations +[ 0.352914] PCI: Using ACPI for IRQ routing +[ 0.353321] PCI: pci_cache_line_size set to 64 bytes +[ 0.353916] e820: reserve RAM buffer [mem 0x00810000-0x008fffff] +[ 0.354487] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff] +[ 0.355053] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff] +[ 0.355719] clocksource: Switched to clocksource kvm-clock +[ 0.355991] pnp: PnP ACPI init +[ 0.355991] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active) +[ 0.355991] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active) +[ 0.355991] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) +[ 0.355991] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) +[ 0.355991] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved +[ 0.356347] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active) +[ 0.357410] pnp: PnP ACPI: found 5 devices +[ 0.362961] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.363871] NET: Registered protocol family 2 +[ 0.364474] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear) +[ 0.365307] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 0.366095] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear) +[ 0.366893] TCP: Hash tables configured (established 16384 bind 16384) +[ 0.367563] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.368255] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.369036] NET: Registered protocol family 1 +[ 0.369533] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.371860] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.372477] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.373092] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.373765] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window] +[ 0.374428] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window] +[ 0.375109] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window] +[ 0.375904] PCI: CLS 0 bytes, default 64 +[ 0.376370] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) +[ 0.377008] software IO TLB: mapped [mem 0x000000006f600000-0x0000000073600000] (64MB) +[ 0.377807] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 0.379980] workingset: timestamp_bits=46 max_order=19 bucket_order=0 +[ 0.381847] fuse: init (API version 7.32) +[ 0.382462] SGI XFS with security attributes, no debug enabled +[ 0.383337] 9p: Installing v9fs 9p2000 file system support +[ 0.383950] NET: Registered protocol family 38 +[ 0.384407] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) +[ 0.385291] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 0.386003] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +[ 0.386731] ACPI: Power Button [PWRF] +[ 0.387428] PCI Interrupt Link [GSIF] enabled at IRQ 21 +[ 0.388885] PCI Interrupt Link [GSIH] enabled at IRQ 23 +[ 0.390255] PCI Interrupt Link [GSIE] enabled at IRQ 20 +[ 0.393749] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +[ 0.394570] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +[ 0.409740] software IO TLB: Memory encryption is active and system is using DMA bounce buffers +[ 0.411320] printk: console [hvc0] enabled +[ 0.413415] brd: module loaded +[ 0.414644] loop: module loaded +[ 0.416081] scsi host0: Virtio SCSI HBA +[ 0.417023] random: fast init done +[ 0.417469] VFIO - User Level meta-driver version: 0.3 +[ 0.418175] random: crng init done +[ 0.418975] xt_time: kernel timezone is -0000 +[ 0.419488] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP) +[ 0.420221] IPVS: Connection hash table configured (size=4096, memory=64Kbytes) +[ 0.421119] IPVS: ipvs loaded. +[ 0.421478] IPVS: [rr] scheduler registered. +[ 0.421979] IPVS: [wrr] scheduler registered. +[ 0.422475] IPVS: [lc] scheduler registered. +[ 0.422970] IPVS: [wlc] scheduler registered. +[ 0.423461] IPVS: [fo] scheduler registered. +[ 0.423982] IPVS: [ovf] scheduler registered. +[ 0.424546] IPVS: [lblc] scheduler registered. +[ 0.425067] IPVS: [lblcr] scheduler registered. +[ 0.425580] IPVS: [dh] scheduler registered. +[ 0.426081] IPVS: [sh] scheduler registered. +[ 0.426572] IPVS: [sed] scheduler registered. +[ 0.427084] IPVS: [nq] scheduler registered. +[ 0.427578] IPVS: ftp: loaded support on port[0] = 21 +[ 0.428167] IPVS: [sip] pe registered. +[ 0.428794] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully +[ 0.429549] Initializing XFRM netlink socket +[ 0.430136] NET: Registered protocol family 10 +[ 0.430960] Segment Routing with IPv6 +[ 0.431417] NET: Registered protocol family 17 +[ 0.431971] 9pnet: Installing 9P2000 support +[ 0.433142] NET: Registered protocol family 40 +[ 0.433718] IPI shorthand broadcast: enabled +[ 0.434218] sched_clock: Marking stable (290414430, 142054672)->(447457221, -14988119) +[ 0.435600] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 +[ 0.436567] Please append a correct "root=" boot option; here are the available partitions: +[ 0.437750] 0100 4096 ram0 +[ 0.437750] (driver?) +[ 0.438478] 0101 4096 ram1 +[ 0.438478] (driver?) +[ 0.439182] 0102 4096 ram2 +[ 0.439183] (driver?) +[ 0.439896] 0103 4096 ram3 +[ 0.439897] (driver?) +[ 0.440629] 0104 4096 ram4 +[ 0.440630] (driver?) +[ 0.441346] 0105 4096 ram5 +[ 0.441346] (driver?) +[ 0.442052] 0106 4096 ram6 +[ 0.442053] (driver?) +[ 0.442756] 0107 4096 ram7 +[ 0.442756] (driver?) +[ 0.443457] 0108 4096 ram8 +[ 0.443457] (driver?) +[ 0.444177] 0109 4096 ram9 +[ 0.444177] (driver?) +[ 0.444893] 010a 4096 ram10 +[ 0.444893] (driver?) +[ 0.445609] 010b 4096 ram11 +[ 0.445610] (driver?) +[ 0.446339] 010c 4096 ram12 +[ 0.446340] (driver?) +[ 0.447056] 010d 4096 ram13 +[ 0.447057] (driver?) +[ 0.447781] 010e 4096 ram14 +[ 0.447781] (driver?) +[ 0.448512] 010f 4096 ram15 +[ 0.448513] (driver?) +[ 0.449263] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) +[ 0.450170] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.25 #1 +[ 0.450848] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.451699] Call Trace: +[ 0.451995] dump_stack+0x57/0x6a +[ 0.452378] panic+0xf6/0x292 +[ 0.452745] mount_block_root+0x2aa/0x324 +[ 0.453197] ? rest_init+0xaa/0xaa +[ 0.453587] prepare_namespace+0x131/0x160 +[ 0.454053] ? rest_init+0xaa/0xaa +[ 0.454442] kernel_init+0x5/0xf6 +[ 0.454838] ret_from_fork+0x22/0x30 +[ 0.455282] Kernel Offset: disabled +[ 0.455676] Rebooting in 1 seconds.. +``` + +Complete output from QEMU 6.2.0 without SEV : +``` +[ 0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021 +[ 0.000000] Command line: 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 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] efi: EFI v2.70 by EDK II +[ 0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e687118 +[ 0.000000] SMBIOS 2.8 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.000000] Hypervisor detected: KVM +[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00 +[ 0.000000] kvm-clock: cpu 0, msr 37201001, primary cpu clock +[ 0.000000] kvm-clock: using sched offset of 2589542167 cycles +[ 0.000002] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns +[ 0.000004] tsc: Detected 2994.372 MHz processor +[ 0.000078] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000081] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000084] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000 +[ 0.000106] MTRR default type: write-back +[ 0.000107] MTRR fixed ranges enabled: +[ 0.000108] 00000-9FFFF write-back +[ 0.000109] A0000-FFFFF uncachable +[ 0.000110] MTRR variable ranges enabled: +[ 0.000111] 0 base 0000C0000000 mask FFFFC0000000 uncachable +[ 0.000111] 1 base 0000B0000000 mask FFFFF0000000 uncachable +[ 0.000112] 2 base 001000000000 mask FFF800000000 uncachable +[ 0.000113] 3 disabled +[ 0.000113] 4 disabled +[ 0.000114] 5 disabled +[ 0.000114] 6 disabled +[ 0.000114] 7 disabled +[ 0.000141] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.004269] Using GB pages for direct mapping +[ 0.004654] Secure boot could not be determined +[ 0.004655] RAMDISK: [mem 0x6f1ee000-0x757f5fff] +[ 0.004668] ACPI: Early table checksum verification disabled +[ 0.004673] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS ) +[ 0.004676] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS BXPC 00000001 01000013) +[ 0.004682] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004686] ACPI: DSDT 0x000000007F979000 003EAE (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004688] ACPI: FACS 0x000000007F9DD000 000040 +[ 0.004690] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004692] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004694] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004696] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004698] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004703] ACPI: Local APIC address 0xfee00000 +[ 0.004734] Zone ranges: +[ 0.004735] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.004736] DMA32 [mem 0x0000000001000000-0x000000007fe5ffff] +[ 0.004737] Normal empty +[ 0.004738] Device empty +[ 0.004739] Movable zone start for each node +[ 0.004740] Early memory node ranges +[ 0.004741] node 0: [mem 0x0000000000001000-0x000000000009ffff] +[ 0.004742] node 0: [mem 0x0000000000100000-0x00000000007fffff] +[ 0.004743] node 0: [mem 0x0000000000808000-0x000000000080ffff] +[ 0.004743] node 0: [mem 0x0000000000900000-0x000000007f6eefff] +[ 0.004744] node 0: [mem 0x000000007f9ff000-0x000000007fe5ffff] +[ 0.004746] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff] +[ 0.004747] On node 0 totalpages: 522743 +[ 0.004748] DMA zone: 59 pages used for memmap +[ 0.004749] DMA zone: 1814 pages reserved +[ 0.004750] DMA zone: 3751 pages, LIFO batch:0 +[ 0.005315] DMA zone: 29017 pages in unavailable ranges +[ 0.005316] DMA32 zone: 8122 pages used for memmap +[ 0.005317] DMA32 zone: 518992 pages, LIFO batch:63 +[ 0.011640] DMA32 zone: 1200 pages in unavailable ranges +[ 0.012025] ACPI: PM-Timer IO Port: 0x608 +[ 0.012028] ACPI: Local APIC address 0xfee00000 +[ 0.012037] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.012063] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23 +[ 0.012065] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.012067] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.012068] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.012069] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.012070] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.012071] ACPI: IRQ0 used by override. +[ 0.012072] ACPI: IRQ5 used by override. +[ 0.012073] ACPI: IRQ9 used by override. +[ 0.012073] ACPI: IRQ10 used by override. +[ 0.012074] ACPI: IRQ11 used by override. +[ 0.012076] Using ACPI (MADT) for SMP configuration information +[ 0.012077] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.012082] TSC deadline timer available +[ 0.012085] smpboot: Allowing 32 CPUs, 31 hotplug CPUs +[ 0.012093] kvm-guest: KVM setup pv remote TLB flush +[ 0.012099] kvm-guest: setup PV sched yield +[ 0.012110] [mem 0xc0000000-0xffffffff] available for PCI devices +[ 0.012116] Booting paravirtualized kernel on KVM +[ 0.012119] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns +[ 0.015048] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1 +[ 0.016599] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144 +[ 0.016605] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152 +[ 0.016606] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15 +[ 0.016611] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31 +[ 0.016637] kvm-guest: KVM setup async PF for cpu 0 +[ 0.016641] kvm-guest: stealtime: cpu 0, msr 6e822080 +[ 0.016645] Built 1 zonelists, mobility grouping on. Total pages: 512748 +[ 0.016646] Kernel command line: 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 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.016721] printk: log_buf_len individual max cpu contribution: 4096 bytes +[ 0.016722] printk: log_buf_len total cpu_extra contributions: 126976 bytes +[ 0.016723] printk: log_buf_len min size: 131072 bytes +[ 0.016904] printk: log_buf_len: 262144 bytes +[ 0.016905] printk: early log buf free: 123296(94%) +[ 0.017240] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) +[ 0.017535] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.017618] mem auto-init: stack:off, heap alloc:off, heap free:off +[ 0.021841] Memory: 1782444K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 308272K reserved, 0K cma-reserved) +[ 0.021920] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1 +[ 0.022033] rcu: Hierarchical RCU implementation. +[ 0.022034] rcu: RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32. +[ 0.022035] All grace periods are expedited (rcu_expedited). +[ 0.022036] Tracing variant of Tasks RCU enabled. +[ 0.022037] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. +[ 0.022038] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32 +[ 0.022058] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16 +[ 0.022381] rcu: Offload RCU callbacks from CPUs: (none). +[ 0.022525] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0 +[ 0.022585] Console: colour dummy device 80x25 +[ 0.103996] printk: console [ttyS0] enabled +[ 0.104387] ACPI: Core revision 20200925 +[ 0.104866] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.105761] APIC: Switch to symmetric I/O mode setup +[ 0.106341] x2apic enabled +[ 0.106708] Switched APIC routing to physical x2apic. +[ 0.107178] kvm-guest: setup PV IPIs +[ 0.108191] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.108739] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 0.109650] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488) +[ 0.113651] pid_max: default: 32768 minimum: 301 +[ 0.129407] LSM: Security Framework initializing +[ 0.129680] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.130330] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.131738] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.132339] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.132849] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.133655] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.134398] Spectre V2 : Mitigation: Full AMD retpoline +[ 0.134857] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.135570] Spectre V2 : Enabling Restricted Speculation for firmware calls +[ 0.136182] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.136913] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp +[ 0.137807] Freeing SMP alternatives memory: 28K +[ 0.138326] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0) +[ 0.141129] Performance Events: Fam17h+ core perfctr, AMD PMU driver. +[ 0.141649] ... version: 0 +[ 0.141657] ... bit width: 48 +[ 0.142342] ... generic registers: 6 +[ 0.143012] ... value mask: 0000ffffffffffff +[ 0.143904] ... max period: 00007fffffffffff +[ 0.144790] ... fixed-purpose events: 0 +[ 0.145529] ... event mask: 000000000000003f +[ 0.145867] rcu: Hierarchical SRCU implementation. +[ 0.147346] smp: Bringing up secondary CPUs ... +[ 0.148411] smp: Brought up 1 node, 1 CPU +[ 0.149351] smpboot: Max logical packages: 32 +[ 0.149660] smpboot: Total of 1 processors activated (5988.74 BogoMIPS) +[ 0.151208] devtmpfs: initialized +[ 0.151830] x86/mm: Memory block size: 128MB +[ 0.152836] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +[ 0.153662] futex hash table entries: 8192 (order: 7, 524288 bytes, linear) +[ 0.155199] NET: Registered protocol family 16 +[ 0.156041] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations +[ 0.157242] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations +[ 0.157661] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations +[ 0.159023] thermal_sys: Registered thermal governor 'step_wise' +[ 0.159027] cpuidle: using governor menu +[ 0.161335] ACPI: bus type PCI registered +[ 0.161655] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 0.162805] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 0.164441] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 0.165592] PCI: Using configuration type 1 for base access +[ 0.166553] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages +[ 0.167679] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.169123] ACPI: Added _OSI(Module Device) +[ 0.169657] ACPI: Added _OSI(Processor Device) +[ 0.170402] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.171180] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.172120] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.172866] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.173655] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.176672] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 0.178693] ACPI: Interpreter enabled +[ 0.179358] ACPI: (supports S0 S5) +[ 0.179937] ACPI: Using IOAPIC for interrupt routing +[ 0.180969] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.181842] ACPI: Enabled 3 GPEs in block 00 to 3F +[ 0.188692] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 0.189662] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] +[ 0.191262] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR] +[ 0.192546] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME PCIeCapability] +[ 0.193820] PCI host bridge to bus 0000:00 +[ 0.194509] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.195642] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.196770] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.197654] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 0.198902] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 0.200182] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window] +[ 0.201533] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.201712] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 0.203324] pci 0000:00:01.0: [1af4:1003] type 00 class 0x078000 +[ 0.205657] pci 0000:00:01.0: reg 0x10: [io 0x60c0-0x60ff] +[ 0.208353] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff] +[ 0.213657] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref] +[ 0.218281] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400 +[ 0.223034] pci 0000:00:03.0: [1af4:1004] type 00 class 0x010000 +[ 0.225394] pci 0000:00:03.0: reg 0x10: [io 0x6080-0x60bf] +[ 0.226822] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff] +[ 0.230911] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref] +[ 0.235919] pci 0000:00:04.0: [1af4:1005] type 00 class 0x00ff00 +[ 0.237656] pci 0000:00:04.0: reg 0x10: [io 0x6120-0x613f] +[ 0.241656] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref] +[ 0.244288] pci 0000:00:05.0: [1af4:1009] type 00 class 0x000200 +[ 0.247672] pci 0000:00:05.0: reg 0x10: [io 0x6040-0x607f] +[ 0.249624] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff] +[ 0.252855] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref] +[ 0.257540] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100 +[ 0.258154] pci 0000:00:1f.0: quirk: [io 0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO +[ 0.259985] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601 +[ 0.264875] pci 0000:00:1f.2: reg 0x20: [io 0x6100-0x611f] +[ 0.267416] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff] +[ 0.269582] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500 +[ 0.271746] pci 0000:00:1f.3: reg 0x20: [io 0x6000-0x603f] +[ 0.274063] pci_bus 0000:01: extended config space not accessible +[ 0.275352] acpiphp: Slot [0] registered +[ 0.276038] acpiphp: Slot [1] registered +[ 0.277675] acpiphp: Slot [2] registered +[ 0.278353] acpiphp: Slot [3] registered +[ 0.279150] acpiphp: Slot [4] registered +[ 0.279837] acpiphp: Slot [5] registered +[ 0.280509] acpiphp: Slot [6] registered +[ 0.281280] acpiphp: Slot [7] registered +[ 0.281677] acpiphp: Slot [8] registered +[ 0.282360] acpiphp: Slot [9] registered +[ 0.283032] acpiphp: Slot [10] registered +[ 0.283814] acpiphp: Slot [11] registered +[ 0.284510] acpiphp: Slot [12] registered +[ 0.285203] acpiphp: Slot [13] registered +[ 0.285678] acpiphp: Slot [14] registered +[ 0.286378] acpiphp: Slot [15] registered +[ 0.287111] acpiphp: Slot [16] registered +[ 0.288055] acpiphp: Slot [17] registered +[ 0.288803] acpiphp: Slot [18] registered +[ 0.289541] acpiphp: Slot [19] registered +[ 0.289674] acpiphp: Slot [20] registered +[ 0.290384] acpiphp: Slot [21] registered +[ 0.291086] acpiphp: Slot [22] registered +[ 0.291778] acpiphp: Slot [23] registered +[ 0.292480] acpiphp: Slot [24] registered +[ 0.293211] acpiphp: Slot [25] registered +[ 0.293674] acpiphp: Slot [26] registered +[ 0.294385] acpiphp: Slot [27] registered +[ 0.295071] acpiphp: Slot [28] registered +[ 0.295953] acpiphp: Slot [29] registered +[ 0.296769] acpiphp: Slot [30] registered +[ 0.297594] acpiphp: Slot [31] registered +[ 0.297916] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.300138] pci_bus 0000:00: on NUMA node 0 +[ 0.301275] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) +[ 0.301748] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) +[ 0.302965] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) +[ 0.304172] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) +[ 0.305263] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) +[ 0.305787] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) +[ 0.306849] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) +[ 0.308110] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) +[ 0.309202] ACPI: PCI Interrupt Link [GSIA] (IRQs *16) +[ 0.309667] ACPI: PCI Interrupt Link [GSIB] (IRQs *17) +[ 0.310565] ACPI: PCI Interrupt Link [GSIC] (IRQs *18) +[ 0.311446] ACPI: PCI Interrupt Link [GSID] (IRQs *19) +[ 0.312329] ACPI: PCI Interrupt Link [GSIE] (IRQs *20) +[ 0.313253] ACPI: PCI Interrupt Link [GSIF] (IRQs *21) +[ 0.313672] ACPI: PCI Interrupt Link [GSIG] (IRQs *22) +[ 0.314722] ACPI: PCI Interrupt Link [GSIH] (IRQs *23) +[ 0.317172] iommu: Default domain type: Translated +[ 0.317728] vgaarb: loaded +[ 0.318310] SCSI subsystem initialized +[ 0.318954] pps_core: LinuxPPS API ver. 1 registered +[ 0.319804] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 0.321326] PTP clock support registered +[ 0.321687] Registered efivars operations +[ 0.322500] PCI: Using ACPI for IRQ routing +[ 0.323211] PCI: pci_cache_line_size set to 64 bytes +[ 0.324206] e820: reserve RAM buffer [mem 0x00810000-0x008fffff] +[ 0.325212] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff] +[ 0.325657] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff] +[ 0.326754] clocksource: Switched to clocksource kvm-clock +[ 0.327844] pnp: PnP ACPI init +[ 0.328425] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active) +[ 0.329649] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active) +[ 0.329809] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) +[ 0.331078] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) +[ 0.332465] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved +[ 0.333902] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active) +[ 0.335579] pnp: PnP ACPI: found 5 devices +[ 0.341670] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.343568] NET: Registered protocol family 2 +[ 0.345189] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear) +[ 0.346697] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 0.348298] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear) +[ 0.349954] TCP: Hash tables configured (established 16384 bind 16384) +[ 0.351468] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.352774] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.354001] NET: Registered protocol family 1 +[ 0.354738] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.359275] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.360332] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.361390] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.362681] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window] +[ 0.364042] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window] +[ 0.365243] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window] +[ 0.366666] PCI: CLS 0 bytes, default 64 +[ 0.367453] Trying to unpack rootfs image as initramfs... +[ 2.474287] Freeing initrd memory: 104480K +[ 2.474789] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 2.476083] workingset: timestamp_bits=46 max_order=19 bucket_order=0 +[ 2.477757] fuse: init (API version 7.32) +[ 2.478215] SGI XFS with security attributes, no debug enabled +[ 2.478997] 9p: Installing v9fs 9p2000 file system support +[ 2.479591] NET: Registered protocol family 38 +[ 2.480035] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) +[ 2.480870] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 2.481582] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +[ 2.482309] ACPI: Power Button [PWRF] +[ 2.482943] PCI Interrupt Link [GSIF] enabled at IRQ 21 +[ 2.484131] PCI Interrupt Link [GSIH] enabled at IRQ 23 +[ 2.485303] PCI Interrupt Link [GSIE] enabled at IRQ 20 +[ 2.486896] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +[ 2.487599] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +[ 2.513070] printk: console [hvc0] enabled +[ 2.514550] brd: module loaded +[ 2.515360] random: fast init done +[ 2.516052] loop: module loaded +[ 2.516563] random: crng init done +[ 2.517477] scsi host0: Virtio SCSI HBA +[ 2.518342] VFIO - User Level meta-driver version: 0.3 +[ 2.519286] xt_time: kernel timezone is -0000 +[ 2.519803] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP) +[ 2.520504] IPVS: Connection hash table configured (size=4096, memory=64Kbytes) +[ 2.521364] IPVS: ipvs loaded. +[ 2.521734] IPVS: [rr] scheduler registered. +[ 2.522232] IPVS: [wrr] scheduler registered. +[ 2.522732] IPVS: [lc] scheduler registered. +[ 2.523234] IPVS: [wlc] scheduler registered. +[ 2.523733] IPVS: [fo] scheduler registered. +[ 2.524237] IPVS: [ovf] scheduler registered. +[ 2.524741] IPVS: [lblc] scheduler registered. +[ 2.525253] IPVS: [lblcr] scheduler registered. +[ 2.525778] IPVS: [dh] scheduler registered. +[ 2.526281] IPVS: [sh] scheduler registered. +[ 2.526770] IPVS: [sed] scheduler registered. +[ 2.527273] IPVS: [nq] scheduler registered. +[ 2.527761] IPVS: ftp: loaded support on port[0] = 21 +[ 2.528335] IPVS: [sip] pe registered. +[ 2.528913] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully +[ 2.529668] Initializing XFRM netlink socket +[ 2.530243] NET: Registered protocol family 10 +[ 2.530990] Segment Routing with IPv6 +[ 2.531446] NET: Registered protocol family 17 +[ 2.531980] 9pnet: Installing 9P2000 support +[ 2.532904] NET: Registered protocol family 40 +[ 2.533452] IPI shorthand broadcast: enabled +[ 2.533957] sched_clock: Marking stable (2450694990, 83251786)->(2555552194, -21605418) +[ 2.535774] Freeing unused decrypted memory: 2036K +[ 2.536717] Freeing unused kernel image (initmem) memory: 892K +[ 2.537482] Write protecting the kernel read-only data: 14336k +[ 2.538869] Freeing unused kernel image (text/rodata gap) memory: 2044K +[ 2.539890] Freeing unused kernel image (rodata/data gap) memory: 592K +[ 2.540714] Run /init as init process +[ 2.541191] with arguments: +[ 2.541582] /init +[ 2.541885] with environment: +[ 2.542325] HOME=/ +[ 2.542640] TERM=linux +``` + +Expected output as previous versions +Complete output from QEMU 6.0.0 with SEV : +``` +[ 0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021 +[ 0.000000] Command line: 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 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] efi: EFI v2.70 by EDK II +[ 0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e9d8118 +[ 0.000000] SMBIOS 2.8 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.000000] Hypervisor detected: KVM +[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00 +[ 0.000000] kvm-clock: cpu 0, msr 14201001, primary cpu clock +[ 0.000001] kvm-clock: using sched offset of 3987202924 cycles +[ 0.000004] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns +[ 0.000006] tsc: Detected 2994.372 MHz processor +[ 0.000158] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000161] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000168] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000 +[ 0.000215] MTRR default type: write-back +[ 0.000216] MTRR fixed ranges enabled: +[ 0.000218] 00000-9FFFF write-back +[ 0.000220] A0000-FFFFF uncachable +[ 0.000220] MTRR variable ranges enabled: +[ 0.000222] 0 base 0000C0000000 mask FFFFC0000000 uncachable +[ 0.000224] 1 base 0000B0000000 mask FFFFF0000000 uncachable +[ 0.000226] 2 base 001000000000 mask FFF800000000 uncachable +[ 0.000227] 3 disabled +[ 0.000227] 4 disabled +[ 0.000228] 5 disabled +[ 0.000229] 6 disabled +[ 0.000230] 7 disabled +[ 0.000274] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.008664] Using GB pages for direct mapping +[ 0.009370] Secure boot could not be determined +[ 0.009372] RAMDISK: [mem 0x6f1ee000-0x757f5fff] +[ 0.009399] ACPI: Early table checksum verification disabled +[ 0.009410] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS ) +[ 0.009415] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS BXPC 00000001 01000013) +[ 0.009423] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009430] ACPI: DSDT 0x000000007F979000 003278 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009435] ACPI: FACS 0x000000007F9DD000 000040 +[ 0.009439] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009443] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009448] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009452] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009456] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009466] ACPI: Local APIC address 0xfee00000 +[ 0.009507] Zone ranges: +[ 0.009508] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.009511] DMA32 [mem 0x0000000001000000-0x000000007fe5ffff] +[ 0.009513] Normal empty +[ 0.009514] Device empty +[ 0.009516] Movable zone start for each node +[ 0.009517] Early memory node ranges +[ 0.009518] node 0: [mem 0x0000000000001000-0x000000000009ffff] +[ 0.009520] node 0: [mem 0x0000000000100000-0x00000000007fffff] +[ 0.009521] node 0: [mem 0x0000000000808000-0x000000000080ffff] +[ 0.009522] node 0: [mem 0x0000000000900000-0x000000007f6eefff] +[ 0.009523] node 0: [mem 0x000000007f9ff000-0x000000007fe5ffff] +[ 0.009525] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff] +[ 0.009528] On node 0 totalpages: 522743 +[ 0.009529] DMA zone: 59 pages used for memmap +[ 0.009531] DMA zone: 1814 pages reserved +[ 0.009532] DMA zone: 3751 pages, LIFO batch:0 +[ 0.009843] DMA zone: 29017 pages in unavailable ranges +[ 0.009845] DMA32 zone: 8122 pages used for memmap +[ 0.009846] DMA32 zone: 518992 pages, LIFO batch:63 +[ 0.014033] DMA32 zone: 1200 pages in unavailable ranges +[ 0.014785] ACPI: PM-Timer IO Port: 0x608 +[ 0.014788] ACPI: Local APIC address 0xfee00000 +[ 0.014803] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.014994] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 +[ 0.014998] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.015001] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.015003] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.015005] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.015006] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.015007] ACPI: IRQ0 used by override. +[ 0.015009] ACPI: IRQ5 used by override. +[ 0.015010] ACPI: IRQ9 used by override. +[ 0.015011] ACPI: IRQ10 used by override. +[ 0.015011] ACPI: IRQ11 used by override. +[ 0.015014] Using ACPI (MADT) for SMP configuration information +[ 0.015017] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.015021] TSC deadline timer available +[ 0.015027] smpboot: Allowing 32 CPUs, 31 hotplug CPUs +[ 0.015039] kvm-guest: KVM setup pv remote TLB flush +[ 0.015048] kvm-guest: setup PV sched yield +[ 0.015065] [mem 0xc0000000-0xffffffff] available for PCI devices +[ 0.015066] Booting paravirtualized kernel on KVM +[ 0.015070] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns +[ 0.020345] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1 +[ 0.021575] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144 +[ 0.021585] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152 +[ 0.021587] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15 +[ 0.021596] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31 +[ 0.027137] kvm-guest: KVM setup async PF for cpu 0 +[ 0.027144] kvm-guest: stealtime: cpu 0, msr 7d622080 +[ 0.027159] Built 1 zonelists, mobility grouping on. Total pages: 512748 +[ 0.027161] Kernel command line: 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 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.027288] printk: log_buf_len individual max cpu contribution: 4096 bytes +[ 0.027290] printk: log_buf_len total cpu_extra contributions: 126976 bytes +[ 0.027291] printk: log_buf_len min size: 131072 bytes +[ 0.027523] printk: log_buf_len: 262144 bytes +[ 0.027524] printk: early log buf free: 123296(94%) +[ 0.027737] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) +[ 0.027850] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.027991] mem auto-init: stack:off, heap alloc:off, heap free:off +[ 0.040909] Memory: 1711324K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 379392K reserved, 0K cma-reserved) +[ 0.041029] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1 +[ 0.041170] rcu: Hierarchical RCU implementation. +[ 0.041171] rcu: RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32. +[ 0.041173] All grace periods are expedited (rcu_expedited). +[ 0.041174] Tracing variant of Tasks RCU enabled. +[ 0.041176] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. +[ 0.041177] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32 +[ 0.041233] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16 +[ 0.041739] rcu: Offload RCU callbacks from CPUs: (none). +[ 0.041913] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0 +[ 0.041995] Console: colour dummy device 80x25 +[ 0.140890] printk: console [ttyS0] enabled +[ 0.154171] AMD Memory Encryption Features active: SEV +[ 0.154858] ACPI: Core revision 20200925 +[ 0.155536] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.156743] APIC: Switch to symmetric I/O mode setup +[ 0.158619] x2apic enabled +[ 0.160959] Switched APIC routing to physical x2apic. +[ 0.161554] kvm-guest: setup PV IPIs +[ 0.168397] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.169300] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 0.170521] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488) +[ 0.171487] pid_max: default: 32768 minimum: 301 +[ 0.202181] LSM: Security Framework initializing +[ 0.202548] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.203685] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.205011] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.205802] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.206525] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.207435] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.208419] Spectre V2 : Mitigation: Full AMD retpoline +[ 0.209026] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.209975] Spectre V2 : Enabling Restricted Speculation for firmware calls +[ 0.210523] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.211737] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp +[ 0.213043] Freeing SMP alternatives memory: 28K +[ 0.213721] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0) +[ 0.214519] Performance Events: Fam17h+ core perfctr, AMD PMU driver. +[ 0.214519] ... version: 0 +[ 0.214519] ... bit width: 48 +[ 0.214519] ... generic registers: 6 +[ 0.214519] ... value mask: 0000ffffffffffff +[ 0.214525] ... max period: 00007fffffffffff +[ 0.215142] ... fixed-purpose events: 0 +[ 0.215616] ... event mask: 000000000000003f +[ 0.216346] rcu: Hierarchical SRCU implementation. +[ 0.217174] smp: Bringing up secondary CPUs ... +[ 0.217714] smp: Brought up 1 node, 1 CPU +[ 0.218184] smpboot: Max logical packages: 32 +[ 0.218527] smpboot: Total of 1 processors activated (5988.74 BogoMIPS) +[ 0.219686] devtmpfs: initialized +[ 0.220119] x86/mm: Memory block size: 128MB +[ 0.220864] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +[ 0.221995] futex hash table entries: 8192 (order: 7, 524288 bytes, linear) +[ 0.222863] NET: Registered protocol family 16 +[ 0.223660] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations +[ 0.224813] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations +[ 0.225857] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations +[ 0.226565] thermal_sys: Registered thermal governor 'step_wise' +[ 0.226569] cpuidle: using governor menu +[ 0.228447] ACPI: bus type PCI registered +[ 0.228925] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 0.229775] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 0.230527] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 0.231331] PCI: Using configuration type 1 for base access +[ 0.232839] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages +[ 0.233641] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.234545] ACPI: Added _OSI(Module Device) +[ 0.235040] ACPI: Added _OSI(Processor Device) +[ 0.235568] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.236115] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.236745] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.237264] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.237886] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.240277] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 0.242125] ACPI: Interpreter enabled +[ 0.242530] ACPI: (supports S0 S5) +[ 0.242933] ACPI: Using IOAPIC for interrupt routing +[ 0.243537] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.244744] ACPI: Enabled 2 GPEs in block 00 to 3F +[ 0.250149] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 0.250531] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] +[ 0.251661] acpi PNP0A08:00: _OSC: platform does not support [LTR] +[ 0.252454] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug SHPCHotplug PME PCIeCapability] +[ 0.253626] PCI host bridge to bus 0000:00 +[ 0.254115] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.254526] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.255309] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.256179] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 0.257045] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 0.257910] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window] +[ 0.258525] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.259223] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 0.260509] pci 0000:00:01.0: [1af4:1043] type 00 class 0x078000 +[ 0.263098] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff] +[ 0.267149] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref] +[ 0.269843] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400 +[ 0.275338] pci 0000:00:03.0: [1af4:1048] type 00 class 0x010000 +[ 0.277811] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff] +[ 0.281320] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref] +[ 0.284951] pci 0000:00:04.0: [1af4:1044] type 00 class 0x00ff00 +[ 0.287749] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref] +[ 0.289851] pci 0000:00:05.0: [1af4:1049] type 00 class 0x000200 +[ 0.292301] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff] +[ 0.295709] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref] +[ 0.298275] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100 +[ 0.299038] pci 0000:00:1f.0: quirk: [io 0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO +[ 0.300211] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601 +[ 0.306084] pci 0000:00:1f.2: reg 0x20: [io 0x6040-0x605f] +[ 0.307285] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff] +[ 0.309200] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500 +[ 0.312072] pci 0000:00:1f.3: reg 0x20: [io 0x6000-0x603f] +[ 0.314207] pci_bus 0000:01: extended config space not accessible +[ 0.314817] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.317358] pci_bus 0000:00: on NUMA node 0 +[ 0.318107] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) +[ 0.318611] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) +[ 0.319355] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) +[ 0.320094] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) +[ 0.320826] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) +[ 0.321565] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) +[ 0.322302] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) +[ 0.322608] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) +[ 0.323292] ACPI: PCI Interrupt Link [GSIA] (IRQs *16) +[ 0.323908] ACPI: PCI Interrupt Link [GSIB] (IRQs *17) +[ 0.324522] ACPI: PCI Interrupt Link [GSIC] (IRQs *18) +[ 0.325132] ACPI: PCI Interrupt Link [GSID] (IRQs *19) +[ 0.325746] ACPI: PCI Interrupt Link [GSIE] (IRQs *20) +[ 0.326356] ACPI: PCI Interrupt Link [GSIF] (IRQs *21) +[ 0.326533] ACPI: PCI Interrupt Link [GSIG] (IRQs *22) +[ 0.327148] ACPI: PCI Interrupt Link [GSIH] (IRQs *23) +[ 0.329169] iommu: Default domain type: Translated +[ 0.329808] vgaarb: loaded +[ 0.330245] SCSI subsystem initialized +[ 0.330537] pps_core: LinuxPPS API ver. 1 registered +[ 0.331124] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 0.332182] PTP clock support registered +[ 0.332667] Registered efivars operations +[ 0.333281] PCI: Using ACPI for IRQ routing +[ 0.333783] PCI: pci_cache_line_size set to 64 bytes +[ 0.334528] e820: reserve RAM buffer [mem 0x00810000-0x008fffff] +[ 0.335230] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff] +[ 0.335932] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff] +[ 0.336675] clocksource: Switched to clocksource kvm-clock +[ 0.337485] pnp: PnP ACPI init +[ 0.337896] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active) +[ 0.338519] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active) +[ 0.338519] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) +[ 0.338519] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) +[ 0.338920] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved +[ 0.339770] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active) +[ 0.341103] pnp: PnP ACPI: found 5 devices +[ 0.346943] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.348014] NET: Registered protocol family 2 +[ 0.348722] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear) +[ 0.349720] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 0.350698] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear) +[ 0.351620] TCP: Hash tables configured (established 16384 bind 16384) +[ 0.352423] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.353213] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.354115] NET: Registered protocol family 1 +[ 0.354654] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.357279] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.358008] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.358744] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.359541] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window] +[ 0.360345] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window] +[ 0.361145] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window] +[ 0.362089] PCI: CLS 0 bytes, default 64 +[ 0.362638] Trying to unpack rootfs image as initramfs... +[ 2.307254] Freeing initrd memory: 104480K +[ 2.307791] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) +[ 2.308521] software IO TLB: mapped [mem 0x0000000069000000-0x000000006d000000] (64MB) +[ 2.309454] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 2.311063] workingset: timestamp_bits=46 max_order=19 bucket_order=0 +[ 2.313608] fuse: init (API version 7.32) +[ 2.314181] SGI XFS with security attributes, no debug enabled +[ 2.315435] 9p: Installing v9fs 9p2000 file system support +[ 2.316233] NET: Registered protocol family 38 +[ 2.316827] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) +[ 2.317926] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 2.318847] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +[ 2.319752] ACPI: Power Button [PWRF] +[ 2.320661] PCI Interrupt Link [GSIF] enabled at IRQ 21 +[ 2.322549] PCI Interrupt Link [GSIH] enabled at IRQ 23 +[ 2.324157] PCI Interrupt Link [GSIE] enabled at IRQ 20 +[ 2.326555] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +[ 2.327388] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +[ 2.341959] software IO TLB: Memory encryption is active and system is using DMA bounce buffers +[ 2.344242] printk: console [hvc0] enabled +[ 2.346335] brd: module loaded +[ 2.347023] random: fast init done +[ 2.347786] random: crng init done +[ 2.349418] loop: module loaded +[ 2.351182] scsi host0: Virtio SCSI HBA +[ 2.352317] VFIO - User Level meta-driver version: 0.3 +[ 2.353380] xt_time: kernel timezone is -0000 +[ 2.354028] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP) +[ 2.354873] IPVS: Connection hash table configured (size=4096, memory=64Kbytes) +[ 2.355859] IPVS: ipvs loaded. +[ 2.356319] IPVS: [rr] scheduler registered. +[ 2.356933] IPVS: [wrr] scheduler registered. +[ 2.357542] IPVS: [lc] scheduler registered. +[ 2.358152] IPVS: [wlc] scheduler registered. +[ 2.358787] IPVS: [fo] scheduler registered. +[ 2.359343] IPVS: [ovf] scheduler registered. +[ 2.359968] IPVS: [lblc] scheduler registered. +[ 2.360595] IPVS: [lblcr] scheduler registered. +[ 2.361236] IPVS: [dh] scheduler registered. +[ 2.361846] IPVS: [sh] scheduler registered. +[ 2.362468] IPVS: [sed] scheduler registered. +[ 2.363060] IPVS: [nq] scheduler registered. +[ 2.363623] IPVS: ftp: loaded support on port[0] = 21 +[ 2.364272] IPVS: [sip] pe registered. +[ 2.364967] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully +[ 2.365818] Initializing XFRM netlink socket +[ 2.366474] NET: Registered protocol family 10 +[ 2.367351] Segment Routing with IPv6 +[ 2.367888] NET: Registered protocol family 17 +[ 2.368518] 9pnet: Installing 9P2000 support +[ 2.369955] NET: Registered protocol family 40 +[ 2.370608] IPI shorthand broadcast: enabled +[ 2.371198] sched_clock: Marking stable (2249797515, 120751625)->(2381329269, -10780129) +[ 2.373554] Freeing unused decrypted memory: 2036K +[ 2.374622] Freeing unused kernel image (initmem) memory: 892K +[ 2.375403] Write protecting the kernel read-only data: 14336k +[ 2.377004] Freeing unused kernel image (text/rodata gap) memory: 2044K +[ 2.378219] Freeing unused kernel image (rodata/data gap) memory: 592K +[ 2.379114] Run /init as init process +[ 2.379599] with arguments: +[ 2.380009] /init +[ 2.380321] with environment: +[ 2.380749] HOME=/ +[ 2.381071] TERM=linux +``` diff --git a/results/classifier/zero-shot/108/none/964 b/results/classifier/zero-shot/108/none/964 new file mode 100644 index 000000000..29952c494 --- /dev/null +++ b/results/classifier/zero-shot/108/none/964 @@ -0,0 +1,55 @@ +KVM: 0.389 +graphic: 0.346 +vnc: 0.342 +debug: 0.340 +other: 0.324 +boot: 0.310 +semantic: 0.292 +device: 0.288 +performance: 0.283 +permissions: 0.277 +network: 0.271 +PID: 0.267 +socket: 0.242 +files: 0.234 + +arm64 defconfig kernel (4.14.275) no longer boots after FEAT_LPA implementation in TCG +Description of problem: +I am not really sure if this is a bug or merely a scenario where this is not expected to work. After 7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf, the attached `Image.gz` (`ARCH=arm64 defconfig`, based on the latest `linux-4.14.y`) just hangs with no output when using `-cpu max` (or `-cpu max,lpa2=off` due to 69b2265d5fe8e0f401d75e175e0a243a7d505e53). At 0af312b6edd231e1c8d0dec12494a80bc39ac761, `-cpu max` works just fine, as shown by the bisect log below. + +``` +$ git bisect log +# bad: [99eb313ddbbcf73c1adcdadceba1423b691c6d05] ui/cocoa: Use the standard about panel +# good: [44f28df24767cf9dca1ddc9b23157737c4cbb645] Update version for v6.2.0 release +git bisect start '99eb313ddbbcf73c1adcdadceba1423b691c6d05' 'v6.2.0' +# good: [2fc1b44dd0e7ea9ad5920352fd04179e4d6836d9] target/riscv: rvv-1.0: Allow Zve32f extension to be turned on +git bisect good 2fc1b44dd0e7ea9ad5920352fd04179e4d6836d9 +# good: [e64e27d5cb103b7764f1a05b6eda7e7fedd517c5] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread +git bisect good e64e27d5cb103b7764f1a05b6eda7e7fedd517c5 +# good: [747ffe28cad7129e1d326d943228fdcbe109530d] pnv/xive2: Add support XIVE2 P9-compat mode (or Gen1) +git bisect good 747ffe28cad7129e1d326d943228fdcbe109530d +# bad: [4377683df969e715e3cb2dbd258e44f9ff51f788] edid: Fix clock of Detailed Timing Descriptor +git bisect bad 4377683df969e715e3cb2dbd258e44f9ff51f788 +# good: [755e8d7cb6ce2ba62d282ffbb367de391fe0cc3d] migration: Move static var in ram_block_from_stream() into global +git bisect good 755e8d7cb6ce2ba62d282ffbb367de391fe0cc3d +# bad: [6629bf78aac7e53f83fd0bcbdbe322e2302dfd1f] Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20220302' into staging +git bisect bad 6629bf78aac7e53f83fd0bcbdbe322e2302dfd1f +# good: [0af312b6edd231e1c8d0dec12494a80bc39ac761] target/arm: Implement FEAT_LVA +git bisect good 0af312b6edd231e1c8d0dec12494a80bc39ac761 +# bad: [dc8bc9d6574aa563ed2fcc0ff495e77a2a2a8faa] target/arm: Report KVM's actual PSCI version to guest in dtb +git bisect bad dc8bc9d6574aa563ed2fcc0ff495e77a2a2a8faa +# bad: [d976de218c534735e307fc4a6c03e3ae764fd419] target/arm: Fix TLBIRange.base for 16k and 64k pages +git bisect bad d976de218c534735e307fc4a6c03e3ae764fd419 +# bad: [13e481c9335582fc7eed12e24e8d4d7068b24ff8] target/arm: Extend arm_fi_to_lfsc to level -1 +git bisect bad 13e481c9335582fc7eed12e24e8d4d7068b24ff8 +# bad: [7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf] target/arm: Implement FEAT_LPA +git bisect bad 7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf +# first bad commit: [7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf] target/arm: Implement FEAT_LPA +``` + +A `4.19.237` kernel boots right up with `-cpu max`/`-cpu max,lpa2=off`. Is this expected behavior given the age of the kernel or is there something else going on here? If this is expected, should we be using something like `-cpu cortex-a72` for these older kernels? +Steps to reproduce: +Run the above command with the attached `Image.gz` and `rootfs.cpio`. +Additional information: +[Image.gz](/uploads/7b25b70f210354663b8e391290d3f39c/Image.gz) +[rootfs.cpio](/uploads/4793be1a500bdf615e212d3379c4c175/rootfs.cpio) diff --git a/results/classifier/zero-shot/108/none/969 b/results/classifier/zero-shot/108/none/969 new file mode 100644 index 000000000..9e5f7c800 --- /dev/null +++ b/results/classifier/zero-shot/108/none/969 @@ -0,0 +1,16 @@ +semantic: 0.594 +graphic: 0.212 +performance: 0.125 +permissions: 0.112 +other: 0.051 +device: 0.044 +files: 0.042 +KVM: 0.031 +vnc: 0.029 +PID: 0.028 +debug: 0.021 +network: 0.021 +boot: 0.006 +socket: 0.003 + +qemu: Georgian translation diff --git a/results/classifier/zero-shot/108/none/974958 b/results/classifier/zero-shot/108/none/974958 new file mode 100644 index 000000000..b22825746 --- /dev/null +++ b/results/classifier/zero-shot/108/none/974958 @@ -0,0 +1,28 @@ +graphic: 0.593 +other: 0.549 +device: 0.491 +semantic: 0.447 +network: 0.290 +socket: 0.230 +files: 0.230 +performance: 0.230 +PID: 0.189 +permissions: 0.184 +debug: 0.164 +vnc: 0.153 +boot: 0.111 +KVM: 0.023 + +It dumps when following this tutorial on hello world os + +http://mikeos.berlios.de/write-your-own-os.html + + +Following the steps, + +it works on ubuntu, + +but on osx, it ALWAYS dumps. + +The referenced website is no longer available, thus setting this ticket to INVALID. Please feel free to re-open it if the information is available somewhere else and you can reproduce it with the latest version of QEMU. + |