diff options
Diffstat (limited to '')
30 files changed, 2768 insertions, 0 deletions
diff --git a/results/classifier/118/none/186 b/results/classifier/118/none/186 new file mode 100644 index 00000000..de4e660c --- /dev/null +++ b/results/classifier/118/none/186 @@ -0,0 +1,31 @@ +risc-v: 0.266 +semantic: 0.235 +VMM: 0.210 +device: 0.204 +permissions: 0.204 +kernel: 0.201 +boot: 0.200 +arm: 0.164 +KVM: 0.159 +socket: 0.151 +register: 0.145 +TCG: 0.144 +PID: 0.142 +ppc: 0.139 +vnc: 0.111 +performance: 0.101 +x86: 0.100 +i386: 0.099 +user-level: 0.093 +mistranslation: 0.087 +hypervisor: 0.085 +network: 0.083 +peripherals: 0.082 +debug: 0.056 +virtual: 0.031 +architecture: 0.025 +graphic: 0.024 +files: 0.019 +assembly: 0.010 + +Audit consistent option usage in documentation diff --git a/results/classifier/118/none/1860053 b/results/classifier/118/none/1860053 new file mode 100644 index 00000000..9885ceb2 --- /dev/null +++ b/results/classifier/118/none/1860053 @@ -0,0 +1,89 @@ +device: 0.445 +mistranslation: 0.380 +performance: 0.371 +socket: 0.298 +debug: 0.287 +architecture: 0.287 +network: 0.277 +permissions: 0.253 +graphic: 0.252 +ppc: 0.243 +PID: 0.238 +VMM: 0.221 +semantic: 0.211 +arm: 0.199 +risc-v: 0.193 +peripherals: 0.191 +user-level: 0.190 +boot: 0.185 +TCG: 0.182 +register: 0.181 +kernel: 0.160 +hypervisor: 0.155 +files: 0.155 +virtual: 0.139 +x86: 0.110 +vnc: 0.107 +KVM: 0.091 +assembly: 0.071 +i386: 0.042 + +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/118/none/1860056 b/results/classifier/118/none/1860056 new file mode 100644 index 00000000..45f36fc6 --- /dev/null +++ b/results/classifier/118/none/1860056 @@ -0,0 +1,71 @@ +architecture: 0.673 +device: 0.656 +graphic: 0.588 +mistranslation: 0.485 +semantic: 0.481 +ppc: 0.462 +performance: 0.441 +PID: 0.378 +files: 0.366 +user-level: 0.318 +register: 0.282 +permissions: 0.269 +boot: 0.268 +arm: 0.255 +debug: 0.205 +socket: 0.166 +vnc: 0.155 +virtual: 0.136 +assembly: 0.127 +VMM: 0.124 +network: 0.092 +x86: 0.092 +TCG: 0.087 +risc-v: 0.079 +peripherals: 0.049 +kernel: 0.043 +i386: 0.040 +hypervisor: 0.032 +KVM: 0.024 + +mips binaries segfault + +Hello World appears to segfault with qemu mips, on a Debian 10.0.0 Buster amd64 host. + +Example: + + +$ cat mips/test/hello.cpp +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +$ mips-linux-gnu-g++ -o hello hello.cpp && ./hello +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Note that 64-bit MIPS and little endian 32-bit MIPS qemu work fine. The problem is limited to big endian 32-bit MIPS. + +Could you attach the version of g++ and qemu? In other words, can you capture the output of: + +mips-linux-gnu-g++ --version + +and + +qemu-mips --version + +? + +Does the problem happen if you compile with "-static" option? + +Yours, +Aleksandar + + +Does the problem exist using c hello world and gcc? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/none/1860575 b/results/classifier/118/none/1860575 new file mode 100644 index 00000000..a96cbccb --- /dev/null +++ b/results/classifier/118/none/1860575 @@ -0,0 +1,90 @@ +architecture: 0.648 +semantic: 0.642 +device: 0.496 +hypervisor: 0.456 +kernel: 0.430 +mistranslation: 0.382 +network: 0.334 +permissions: 0.324 +performance: 0.324 +socket: 0.306 +ppc: 0.292 +user-level: 0.264 +virtual: 0.264 +files: 0.254 +debug: 0.246 +vnc: 0.244 +VMM: 0.240 +PID: 0.233 +boot: 0.230 +register: 0.228 +risc-v: 0.217 +assembly: 0.192 +peripherals: 0.175 +KVM: 0.175 +TCG: 0.172 +arm: 0.155 +x86: 0.140 +graphic: 0.105 +i386: 0.102 + +qemu64 CPU model is incorrect + +At the moment the "qemu64" CPU is defined as follows: + +``` + .vendor = CPUID_VENDOR_AMD, + .family = 6, + .model = 6, + .stepping = 3, +``` + +According to Wikipedia [1] this means the CPU is defined as part of the +K7 family while the AMD64 ISA was only introduced with the K8 series! + +This causes some software such as LLVM to notice the problem (32-bit cpu +with 64-bit capability reported in the cpuid flag) and produce various +error messages. + +The simple solution would be to upgrade this definition to use the Sledgehammer +family (15) instead. + +[1] https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures + +Your analysis of the problem with family makes sense & we do have mechanism to fix this in QEMU while keeping back compat for existing deployments. + +I'm curious as to the actual errors LLVM reports ? + +FWIW, even though qemu64 is the default CPU, practically everyone would be better off choosing one of the other CPU models explicitly to better suit their desired use case. There is some guidance here https://qemu.weilnetz.de/doc/qemu-doc.html#cpu_005fmodels + + +The error message is a rather cryptic "LLVM ERROR: 64-bit code requested on a subtarget +that doesn't support it!" as it knows Athlon CPUs don't support the AMD64 ISA. + +I will relay the tip to the people managing the VMs, I guess this problem went unnoticed +for so long because there are not many `qemu64` users. + +I'm available to test a patch whenever it becomes available, I didn't directly send one +because I was afraid of breaking the backward compatibility and some (many?) VMs. + +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/191 + + diff --git a/results/classifier/118/none/1860610 b/results/classifier/118/none/1860610 new file mode 100644 index 00000000..f3d533e4 --- /dev/null +++ b/results/classifier/118/none/1860610 @@ -0,0 +1,50 @@ +graphic: 0.334 +semantic: 0.270 +user-level: 0.203 +performance: 0.179 +device: 0.171 +ppc: 0.166 +architecture: 0.158 +i386: 0.147 +x86: 0.147 +risc-v: 0.141 +kernel: 0.137 +socket: 0.134 +network: 0.115 +debug: 0.108 +mistranslation: 0.108 +vnc: 0.096 +virtual: 0.091 +assembly: 0.076 +hypervisor: 0.053 +arm: 0.051 +boot: 0.050 +PID: 0.048 +register: 0.045 +VMM: 0.036 +peripherals: 0.036 +TCG: 0.033 +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/118/none/1860742 b/results/classifier/118/none/1860742 new file mode 100644 index 00000000..d6c3bc18 --- /dev/null +++ b/results/classifier/118/none/1860742 @@ -0,0 +1,92 @@ +architecture: 0.758 +kernel: 0.727 +boot: 0.589 +device: 0.575 +x86: 0.564 +permissions: 0.536 +ppc: 0.521 +PID: 0.476 +socket: 0.468 +user-level: 0.412 +graphic: 0.374 +assembly: 0.366 +hypervisor: 0.340 +semantic: 0.336 +performance: 0.335 +files: 0.327 +VMM: 0.325 +peripherals: 0.301 +i386: 0.301 +vnc: 0.292 +virtual: 0.279 +arm: 0.257 +mistranslation: 0.252 +risc-v: 0.247 +debug: 0.234 +network: 0.213 +register: 0.189 +TCG: 0.170 +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/118/none/1860914 b/results/classifier/118/none/1860914 new file mode 100644 index 00000000..ee95803a --- /dev/null +++ b/results/classifier/118/none/1860914 @@ -0,0 +1,84 @@ +device: 0.624 +kernel: 0.612 +user-level: 0.569 +boot: 0.564 +semantic: 0.483 +mistranslation: 0.472 +ppc: 0.443 +network: 0.437 +risc-v: 0.427 +graphic: 0.415 +performance: 0.414 +hypervisor: 0.406 +vnc: 0.403 +PID: 0.394 +permissions: 0.388 +x86: 0.387 +TCG: 0.382 +architecture: 0.381 +VMM: 0.373 +arm: 0.370 +socket: 0.360 +i386: 0.353 +register: 0.339 +debug: 0.336 +files: 0.336 +KVM: 0.335 +assembly: 0.298 +peripherals: 0.281 +virtual: 0.180 + +QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification + +When QEMU is launched with the -kernel option to boot a Multiboot image, the command line passed in the -append option is additionally prefixed the pathname of the kernel image and a space. Likewise, module command lines passed in the -initrd option are passed with the module pathname and a space prepended. At the very least the former is contary to what is prescribed in the Multiboot specification, version 0.6.96[0], which says in §3.3: + +> General-purpose boot loaders should allow user a complete control on command line independently of other factors like image name. + +With respect to module command lines, the spec is less clear, but GNU GRUB2 (the de facto reference implementation) does not prepend pathnames to command lines of either. I haven't tested GRUB legacy, but I assume it exhibits the same behaviour. It would be strange if passing pathnames was in fact intended; bootloader pathnames are useless to the loaded kernel, which may potentially have a completely different view of the file system from the bootloader. + +Also, given that a kernel pathname may contain spaces, skipping it in the command line cannot be done reliably, while loading a Multiboot module from a pathname that contains spaces is outright impossible. + +Found in 4.2.0, but latest git master apparently behaves the same. + +[0]: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/425 + + diff --git a/results/classifier/118/none/1860920 b/results/classifier/118/none/1860920 new file mode 100644 index 00000000..29c3450a --- /dev/null +++ b/results/classifier/118/none/1860920 @@ -0,0 +1,68 @@ +user-level: 0.785 +debug: 0.780 +mistranslation: 0.736 +device: 0.697 +semantic: 0.681 +performance: 0.681 +architecture: 0.665 +files: 0.605 +network: 0.592 +socket: 0.500 +boot: 0.497 +register: 0.491 +peripherals: 0.487 +PID: 0.462 +risc-v: 0.429 +virtual: 0.427 +kernel: 0.416 +hypervisor: 0.379 +permissions: 0.377 +x86: 0.375 +graphic: 0.362 +ppc: 0.320 +VMM: 0.319 +vnc: 0.311 +TCG: 0.309 +arm: 0.193 +i386: 0.180 +assembly: 0.160 +KVM: 0.126 + +qemu-s390x-softmmu: crash + +Trying to compile and use rust programs on an s390x emulated machine, crash in qemu/target/s390x/translate.c line 3894 + +Steps to reproduce: +on a amd64 PC, installed debian on s390x emulated by qemu, seems to work fine (installed some packages, etc.) +installed rust cargo (both from rustup and from debian) +cargo install anything makes *qemu* crash when beginning to compile + +Technical details: +* host: amd64 Linux +* qemu v4.2.0 (recompiled from git with debug options using configure --target-list=s390x-softmmu --enable-debug) (problem appears also with older versions of qemu from git, with default compilation options, with qemu from debian, etc.) +* compiled with gcc 9.2 +* command line, relevant part: qemu-system-s390x -snapshot -machine s390-ccw-virtio -cpu max,zpci=on -serial mon:stdio -display none -m 512 +(tested with -smp 4 -m 4096 as well and without snapshotting) +* command line, less relevant part: -drive file=./debian.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-ccw,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,scsi=off -netdev user,id=mynet0,hostfwd=tcp::2223-:22 -device virtio-net-pci,netdev=mynet0 +* core dump: abort in qemu/target/s390x/translate.c line 3894 ; s->field: op has value 0xEC and op2 has value 0x54 +(more info available if needed) + +Tried to patch source to add 0x54 case to no avail. +Tried other cpu variants to no avail as well. + +Reporting this in security as well since it also looks very much like a DoS (albeit somewhat minor), feel free to tell me to report the bug somewhere else. + +There is definitely something wrong here ;-) According to the "Principles of Operations" ISA document, opcode 0xEC54 is the RNSBG instruction (ROTATE THEN AND SELECTED BITS). But op_rosbg() apparently currently handles 0xEC55, 0xEC56 and 0xEC57. 0xEC55 seems wrong there, since this opcode should be handled by op_risbg() instead (according to target/s390x/insn-data.def). So the "case 0x55" seems to be a typo. Does it work if you replace "case 0x55" with "case 0x54" ? + +Suggested patch: +https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg07514.html +"target/s390x/translate: Fix RNSBG instruction" + +Sorry for delay in answering, replacing 0x55 by 0x54 works fine for me. + +Thanks. + + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0bab189c96c7 + diff --git a/results/classifier/118/none/1861468 b/results/classifier/118/none/1861468 new file mode 100644 index 00000000..2cfe2bb3 --- /dev/null +++ b/results/classifier/118/none/1861468 @@ -0,0 +1,53 @@ +device: 0.729 +architecture: 0.686 +graphic: 0.549 +performance: 0.545 +user-level: 0.530 +PID: 0.511 +files: 0.488 +arm: 0.482 +mistranslation: 0.455 +register: 0.437 +debug: 0.422 +permissions: 0.381 +hypervisor: 0.376 +socket: 0.371 +semantic: 0.344 +peripherals: 0.335 +x86: 0.300 +kernel: 0.286 +i386: 0.265 +network: 0.261 +assembly: 0.244 +VMM: 0.241 +TCG: 0.233 +vnc: 0.216 +ppc: 0.190 +risc-v: 0.175 +KVM: 0.166 +boot: 0.148 +virtual: 0.099 + +always fail to build qemu statically + +I want to build qemu statically so as to use qemu on Android platform(Though Limbo emulator is available on github,it's even slower than qemu in UserLAnd(an Android APP that provides proot container for Linux dists)). +When I finished building qemu normally on my phone(Ubuntu devel in proot environment),I started to build qemu statically.I removed the old source code dir and unpack the qemu source code. I had built many libraries like libSDL2 and libiSCSI for qemu,and of course these libraries were able to be detected by qemu configure program.But when I ran the command: + + ❯ ./configure --static --prefix=/home/admin/qemu/build --target-list=aarch64-softmmu,x86_64-softmmu,i386-softmmu,mips64-softmmu,ppc64-softmmu --enable-sdl ERROR: User requested feature sdl +configure was not able to find it. +Install SDL2 devel + +I had to give up the SDL feature. +I disabled the SDL feature and ran configure again.The configure didn't report error,but besides SDL ,many other libraries like libUSB,libpng were missing.I ran 'make -j8 &&make install'.All seemed perfect.But when it comes to the final process--linking executables,the ld program went wrong.It said it could not find the libraries like -lgtk3 -ldrm -lsystemd,etc. +I was confused.I had already had a test building which successfully finished. +Could you give me a possible way to solve the problem? + +Platform information: +Ubuntu devel 20.04 ARM64 with GCC 9.2.1 +QEMU version:I have tested almost all versions from 2.11 to 4.2.0. + +QEMU is not really intended to be built statically except for the 'linux-user' emulators. The configure script will allow you to build the system emulator binaries and the tools statically, but that is more on a "if it happens to work for you, great" basis, rather than a supported one. + +In general: you need to have static library versions of all the development packages like libsdl2, libglib, libgtk, etc etc -- it sounds like you have only the dynamic libraries available, in which case statically linking them will not work, and configure will either note that it couldn't use the package (as happened with SDL) or just not be able to link at the end. You will have better luck also if you use configure --disable... options to reduce the use of optional stuff like libiSCSI which you probably don't need. Then you can avoid having to find static versions of those libraries. + + diff --git a/results/classifier/118/none/1861562 b/results/classifier/118/none/1861562 new file mode 100644 index 00000000..b94478c3 --- /dev/null +++ b/results/classifier/118/none/1861562 @@ -0,0 +1,204 @@ +risc-v: 0.620 +virtual: 0.585 +register: 0.575 +user-level: 0.559 +mistranslation: 0.534 +permissions: 0.533 +hypervisor: 0.496 +device: 0.489 +semantic: 0.487 +VMM: 0.487 +debug: 0.477 +ppc: 0.476 +vnc: 0.466 +peripherals: 0.463 +arm: 0.462 +assembly: 0.456 +architecture: 0.455 +kernel: 0.450 +files: 0.438 +PID: 0.433 +TCG: 0.431 +boot: 0.422 +performance: 0.419 +graphic: 0.418 +socket: 0.410 +KVM: 0.402 +x86: 0.385 +i386: 0.343 +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/118/none/1861605 b/results/classifier/118/none/1861605 new file mode 100644 index 00000000..14904f28 --- /dev/null +++ b/results/classifier/118/none/1861605 @@ -0,0 +1,54 @@ +architecture: 0.753 +performance: 0.673 +device: 0.657 +TCG: 0.646 +mistranslation: 0.642 +kernel: 0.613 +network: 0.611 +socket: 0.595 +ppc: 0.586 +files: 0.578 +register: 0.517 +debug: 0.486 +vnc: 0.481 +peripherals: 0.469 +PID: 0.464 +semantic: 0.463 +assembly: 0.435 +user-level: 0.411 +graphic: 0.403 +risc-v: 0.391 +arm: 0.381 +VMM: 0.375 +x86: 0.365 +virtual: 0.351 +hypervisor: 0.344 +permissions: 0.338 +boot: 0.289 +i386: 0.283 +KVM: 0.192 + +LL/SC broken for MIPS after 7dd547e5ab6b31e7a0cfc182d3ad131dd55a948f + +In that commit the env->llval value is loaded as an unsigned value (instead of sign-extended as before and therefore the CMPXCHG in gen_st_cond() in translate.c fails. + +I have committed a fix for this issue as https://github.com/CTSRD-CHERI/qemu/commit/a18d80c629989d002794f558968e1561edaf3dfd + +An alternative solution would be to change the cmpxchg line to perform a non-sign-extended compare, i.e. replace + tcg_gen_atomic_cmpxchg_tl(t0, addr, cpu_llval, val, + eva ? MIPS_HFLAG_UM : ctx->mem_idx, tcg_mo); +with + tcg_gen_atomic_cmpxchg_tl(t0, addr, cpu_llval, val, + eva ? MIPS_HFLAG_UM : ctx->mem_idx, tcg_mo & ~MO_SIGN); + + +I cannot send this patch to the QEMU mailing list as I am not able to setup git-send-email. +Feel free to apply this commit or the alternative solution. + +The fix I linked is incorrect, the correct URL is https://github.com/CTSRD-CHERI/qemu/commit/a833317eeb0387dcfa7615a78e74f8b48990b8bc + +New patch: https://github.com/qemu/qemu/commit/6ff8dec97f1a105d0da96c67ee24c75e437df162 + +Patch has been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ec860426dfbebe0c + diff --git a/results/classifier/118/none/1861692 b/results/classifier/118/none/1861692 new file mode 100644 index 00000000..9524b277 --- /dev/null +++ b/results/classifier/118/none/1861692 @@ -0,0 +1,45 @@ +graphic: 0.652 +files: 0.610 +device: 0.585 +vnc: 0.543 +network: 0.500 +semantic: 0.462 +permissions: 0.440 +architecture: 0.417 +register: 0.401 +i386: 0.379 +risc-v: 0.356 +ppc: 0.321 +virtual: 0.307 +peripherals: 0.303 +VMM: 0.299 +socket: 0.298 +user-level: 0.291 +performance: 0.288 +PID: 0.283 +debug: 0.282 +x86: 0.281 +hypervisor: 0.264 +kernel: 0.257 +mistranslation: 0.243 +TCG: 0.242 +KVM: 0.231 +boot: 0.209 +arm: 0.152 +assembly: 0.125 + +wavcapture does not record silence + +Using setup described in https://bugs.launchpad.net/qemu/+bug/1861677 a wav file is generated with all the silences stripped out. IOW silence frames are not recorded. + +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/195 + + diff --git a/results/classifier/118/none/1862110 b/results/classifier/118/none/1862110 new file mode 100644 index 00000000..f7c7270e --- /dev/null +++ b/results/classifier/118/none/1862110 @@ -0,0 +1,128 @@ +boot: 0.765 +user-level: 0.685 +network: 0.650 +device: 0.648 +ppc: 0.645 +arm: 0.638 +mistranslation: 0.634 +permissions: 0.629 +risc-v: 0.617 +TCG: 0.608 +semantic: 0.599 +performance: 0.595 +hypervisor: 0.594 +socket: 0.593 +graphic: 0.592 +PID: 0.587 +x86: 0.561 +KVM: 0.559 +peripherals: 0.552 +vnc: 0.539 +kernel: 0.535 +virtual: 0.512 +VMM: 0.510 +architecture: 0.509 +register: 0.506 +debug: 0.498 +i386: 0.496 +assembly: 0.446 +files: 0.440 + +qemu in script is not parsing properly + +Bug Report: +>>qemu-system-x86_64 --version: QEMU emulator version 4.2.0 +>>Arch-linux version 2020.02.01 +I was following a tutorial on how to make a windows vm and i have encountered and issue in the settings of my script I have listed below. + +The commented code directly above the uncommented qemu instance would boot the Windows screen but the issue arises when I try to reach the same code block under the commented setting lines which takes me to the default SeaBIOS loader. + + +#!/bin/bash + +vmname="windows10vm" + +if ps -ef | grep qemu-system-x86_64 | grep -q multifunction=on; then +echo "A passthrough VM is already running." & +exit 1 + +else + +# use pulseaudio + +export QEMU_AUDIO_DRV=pa +export QEMU_PA_SAMPLES=8192 +export QEMU_AUDIO_TIMER_PERIOD=99 +export QEMU_PA_SERVER=/run/user/1000/pulse/native + +cp /usr/share/ovmf/x64/OVMF_VARS.fd /tmp/my_vars.fd + +#qemu-system-x86_64 \ +#-drive id=disk0,if=virtio,cache=none,format=raw,file=.../IMGs/win.img \ +#-drive file=.../ISOs/Win10_1909_English_x64.iso,index=1,media=cdrom \ + +qemu-system-x86_64 \ + +#-name $vmname,process=$vmname \ +#-machine type=q35,accel=kvm \ +#-cpu host,kvm=off \ +#-smp 4,sockets=1,cores=3,threads=1 \ +#-m 8G \ +#-balloon none \ +#-rtc clock=host,base=localtime \ +#-vga none \ +#-nographic \ +#-serial none \ +#-parallel none \ +#-soundhw hda \ +#-usb \ +#-device usb-host,vendorid=...,productid=... \ +#-device usb-host,vendorid=...,productid=... \ +#-device vfio-pci,host=...,multifunction=on \ +#-device vfio-pci,host=... \ +#-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_VARS.fd \ +#-drive if=pflash,format=raw,file=/tmp/my_vars.fd \ +#-boot order= dc \ + +-drive id=disk0,if=virtio,cache=none,format=raw,file=.../IMGs/win.img \ +-drive file=.../ISOs/Win10_1909_English_x64.iso,index=1,media=cdrom \ +-drive file=.../ISOs/virtio-0.1.171.iso,index=2,media=cdrom \ + +#-netdev type=tap,id=net0,ifname=vmtap0,vhost=on \ +#-device virtio-net-pci,netdev=net0,mac=... \ + +exit 0 + +fi + +EDIT: The backslash under the ovmf setting was commented + +Your script is broken, you cannot mix continued lines, blank lines, and comments. Take for instance this example: + +--- +#!/bin/bash + +echo Hello \ +World + +echo Hello \ + +World + +echo Hello \ + +# Earth + +World +--- + +Which results in: + +$ ./hello.sh +Hello World +Hello +./hello.sh: line 8: World: command not found +Hello +./hello.sh: line 14: World: command not found + + diff --git a/results/classifier/118/none/1862986 b/results/classifier/118/none/1862986 new file mode 100644 index 00000000..e42f1d4d --- /dev/null +++ b/results/classifier/118/none/1862986 @@ -0,0 +1,172 @@ +register: 0.523 +user-level: 0.489 +mistranslation: 0.481 +graphic: 0.420 +device: 0.412 +permissions: 0.404 +debug: 0.359 +semantic: 0.359 +assembly: 0.339 +architecture: 0.337 +risc-v: 0.326 +files: 0.318 +PID: 0.309 +arm: 0.299 +network: 0.281 +performance: 0.278 +KVM: 0.268 +kernel: 0.262 +TCG: 0.261 +virtual: 0.257 +socket: 0.248 +boot: 0.211 +ppc: 0.211 +peripherals: 0.208 +vnc: 0.182 +hypervisor: 0.181 +VMM: 0.169 +x86: 0.169 +i386: 0.147 + +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/118/none/1863023 b/results/classifier/118/none/1863023 new file mode 100644 index 00000000..bc53ad06 --- /dev/null +++ b/results/classifier/118/none/1863023 @@ -0,0 +1,88 @@ +risc-v: 0.729 +mistranslation: 0.638 +KVM: 0.623 +user-level: 0.600 +virtual: 0.555 +TCG: 0.546 +x86: 0.537 +VMM: 0.516 +ppc: 0.497 +peripherals: 0.496 +permissions: 0.489 +hypervisor: 0.486 +vnc: 0.472 +performance: 0.430 +semantic: 0.411 +architecture: 0.404 +graphic: 0.400 +kernel: 0.399 +debug: 0.398 +i386: 0.390 +register: 0.389 +boot: 0.388 +network: 0.385 +device: 0.384 +arm: 0.379 +assembly: 0.378 +files: 0.361 +socket: 0.344 +PID: 0.330 + +Deadlock in QXL + +This is on qemu 4.2.0 OSX host, running fresh Windows 7 with SPICE guest tools just installed. + +Command line: `qemu-system-x86_64 -qmp tcp:localhost:4444,server,nowait -smp cpus=2 -boot order=d -m 2048 -soundhw hda -drive file=hda.img,if=ide,media=disk -spice port=5930,addr=127.0.0.1,disable-ticketing,image-compression=off,playback-compression=off,streaming-video=off -vga qxl -device rtl8139,netdev=net0 -netdev user,id=net0` + +After the Windows logo, the screen is black. I dump the two vCPU threads: + +``` +* thread #16 + * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10 + frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701 + frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e8d0, mutex=0x000000011120ba48, file="cpus-common.c", line=144) at qemu-thread-posix.c:173:11 [opt] + frame #3: 0x0000000110926a59 qemu-system-x86_64`do_run_on_cpu(cpu=<unavailable>, func=<unavailable>, data=<unavailable>, mutex=0x000000011120ba48) at cpus-common.c:144:9 [opt] + frame #4: 0x000000011080c50a qemu-system-x86_64`memory_region_snapshot_and_clear_dirty at memory.c:2595:5 [opt] + frame #5: 0x000000011080c4d7 qemu-system-x86_64`memory_region_snapshot_and_clear_dirty(mr=<unavailable>, addr=0, size=2359296, client=<unavailable>) at memory.c:2107 [opt] + frame #6: 0x0000000110849fe1 qemu-system-x86_64`vga_update_display [inlined] vga_draw_graphic(s=<unavailable>, full_update=0) at vga.c:1661:16 [opt] + frame #7: 0x000000011084996a qemu-system-x86_64`vga_update_display(opaque=<unavailable>) at vga.c:1785 [opt] + frame #8: 0x00000001109b261d qemu-system-x86_64`qxl_hard_reset(d=0x00007f84f8730000, loadvm=0) at qxl.c:1285:5 [opt] + frame #9: 0x000000011080ac97 qemu-system-x86_64`memory_region_write_accessor(mr=0x00007f84f8741fb0, addr=5, value=<unavailable>, size=1, shift=<unavailable>, mask=<unavailable>, attrs=MemTxAttrs @ 0x000070000786d890) at memory.c:483:5 [opt] + frame #10: 0x000000011080ab31 qemu-system-x86_64`memory_region_dispatch_write [inlined] access_with_adjusted_size(addr=<unavailable>, value=0x00000000015c6100, size=<unavailable>, access_size_min=<unavailable>, access_size_max=<unavailable>, access_fn=<unavailable>, mr=<unavailable>, attrs=<unavailable>) at memory.c:544:18 [opt] + frame #11: 0x000000011080aafd qemu-system-x86_64`memory_region_dispatch_write(mr=<unavailable>, addr=<unavailable>, data=22831360, op=32644, attrs=MemTxAttrs @ 0x000070000786d8c0) at memory.c:1475 [opt] + frame #12: 0x00000001107b080d qemu-system-x86_64`address_space_stb(as=<unavailable>, addr=<unavailable>, val=22831360, attrs=MemTxAttrs @ r12, result=0x0000000000000000) at memory_ldst.inc.c:378:13 [opt] + frame #13: 0x0000000118570230 + +* thread #18 + * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10 + frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701 + frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e860, mutex=0x000000011121e818, file="cpus-common.c", line=196) at qemu-thread-posix.c:173:11 [opt] + frame #3: 0x0000000110926c44 qemu-system-x86_64`start_exclusive at cpus-common.c:196:9 [opt] + frame #4: 0x0000000110837c35 qemu-system-x86_64`cpu_exec_step_atomic(cpu=0x00007f8518290000) at cpu-exec.c:265:9 [opt] + frame #5: 0x00000001107fcf95 qemu-system-x86_64`qemu_tcg_cpu_thread_fn(arg=0x00007f8518290000) at cpus.c:1799:17 [opt] + frame #6: 0x0000000110bf911e qemu-system-x86_64`qemu_thread_start(args=<unavailable>) at qemu-thread-posix.c:519:9 [opt] + frame #7: 0x00007fff52466e65 libsystem_pthread.dylib`_pthread_start + 148 + frame #8: 0x00007fff5246283b libsystem_pthread.dylib`thread_start + 15 +``` + +Seems like thread #16 had a STB to QXL MMIO registers which caused it to call `qxl_hard_reset` and eventually made its way to `do_run_on_cpu` which waits for `qemu_work_cond`. The only way `qemu_work_cond` is set is if one of the two vCPU executes the queued work at the end of the TCG execution. Thread #16 is stuck waiting, so what about thread #18? Thread #18 is waiting for `exclusive_cond` which is set once all the other CPUs are done running (but thread #16 is waiting still). So classic deadlock. + +Any change if you remove the graphic_hw_update() call in qxl_enter_vga_mode()? + +I can't see where the do_run_on_cpu is called in memory.c at 4.2. Is it reproducible on the latest state of master. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/none/1863441 b/results/classifier/118/none/1863441 new file mode 100644 index 00000000..2305a3fa --- /dev/null +++ b/results/classifier/118/none/1863441 @@ -0,0 +1,61 @@ +ppc: 0.748 +device: 0.729 +semantic: 0.705 +mistranslation: 0.688 +files: 0.670 +graphic: 0.652 +architecture: 0.616 +vnc: 0.607 +performance: 0.604 +socket: 0.601 +register: 0.594 +kernel: 0.583 +user-level: 0.573 +PID: 0.561 +permissions: 0.550 +network: 0.548 +risc-v: 0.516 +arm: 0.511 +debug: 0.503 +peripherals: 0.496 +boot: 0.478 +hypervisor: 0.462 +assembly: 0.452 +VMM: 0.449 +TCG: 0.409 +i386: 0.402 +x86: 0.392 +virtual: 0.368 +KVM: 0.330 + +cmd_mode_sense always reports 0x70, no CDROM present + +cmd_mode_sense + https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/atapi.c;hb=refs/heads/master#l852 +always reports 0x70 in byte 2 returned, indicating no CD-ROM present. + +If CD-ROM is present, should report 0x01 (or 0x11). +If CD-ROM absent, should report 0x70. + +Hi, if you can quote the relevant spec, would you like to include that in a commit message and send a patch? + +Also, does this result in a bug anywhere visible that we can test against? + +Since I posted this bug report, I have done a little more research and this specific part of this command is actually quite obsolete. It use to be documented (MMC v1.2 Draft), but later versions have actually removed this part of the command, even stating "obsolete" in some of the documentation. + +If you want to still allow it, it actually does state 0x70 is an empty drive. However, being it is so obsolete, you may wish to change this status to closed. + +Thanks for asking. I don't mind if you close this bug report. + +Ben + +Roger that, thanks! + +I don't think we're very careful about which version we try to emulate. In practice it's "Whatever seems to work across the largest swatch of guest operating systems simultaneously". + +If this comes up again, feel free to file against a specific guest OS that appears to be non-functioning. + +Thanks! + +--js + diff --git a/results/classifier/118/none/1863445 b/results/classifier/118/none/1863445 new file mode 100644 index 00000000..8fb30238 --- /dev/null +++ b/results/classifier/118/none/1863445 @@ -0,0 +1,73 @@ +x86: 0.676 +TCG: 0.574 +debug: 0.540 +mistranslation: 0.473 +device: 0.454 +PID: 0.448 +socket: 0.412 +architecture: 0.385 +vnc: 0.378 +performance: 0.364 +VMM: 0.344 +hypervisor: 0.327 +ppc: 0.321 +kernel: 0.300 +user-level: 0.292 +arm: 0.292 +network: 0.288 +semantic: 0.272 +i386: 0.254 +virtual: 0.246 +register: 0.238 +risc-v: 0.219 +boot: 0.200 +assembly: 0.192 +permissions: 0.181 +files: 0.172 +peripherals: 0.134 +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/118/none/1863601 b/results/classifier/118/none/1863601 new file mode 100644 index 00000000..087aa9b1 --- /dev/null +++ b/results/classifier/118/none/1863601 @@ -0,0 +1,56 @@ +mistranslation: 0.571 +graphic: 0.531 +semantic: 0.475 +device: 0.328 +user-level: 0.320 +performance: 0.307 +ppc: 0.257 +x86: 0.183 +i386: 0.173 +network: 0.147 +virtual: 0.132 +peripherals: 0.131 +vnc: 0.127 +socket: 0.126 +hypervisor: 0.114 +PID: 0.106 +debug: 0.105 +architecture: 0.097 +register: 0.088 +kernel: 0.077 +boot: 0.065 +assembly: 0.062 +risc-v: 0.060 +arm: 0.060 +TCG: 0.058 +permissions: 0.048 +files: 0.040 +VMM: 0.036 +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/118/none/1864536 b/results/classifier/118/none/1864536 new file mode 100644 index 00000000..80732474 --- /dev/null +++ b/results/classifier/118/none/1864536 @@ -0,0 +1,81 @@ +peripherals: 0.778 +permissions: 0.749 +architecture: 0.742 +virtual: 0.726 +user-level: 0.715 +graphic: 0.713 +performance: 0.705 +device: 0.676 +network: 0.664 +mistranslation: 0.644 +files: 0.638 +assembly: 0.632 +debug: 0.628 +socket: 0.617 +kernel: 0.613 +hypervisor: 0.608 +PID: 0.606 +semantic: 0.593 +ppc: 0.589 +arm: 0.575 +x86: 0.568 +risc-v: 0.567 +register: 0.561 +vnc: 0.552 +VMM: 0.550 +i386: 0.519 +boot: 0.509 +TCG: 0.468 +KVM: 0.330 + +Support for XSAVES intel instructions in QEMU + +Dear QEMU developers, + +I am running Hyper-V on qemu+kvm. During it initialization, it checks for XSAVES support: first it executes CPUID with EAX = 0xd and ECX = 1 and looks at bit 3 in the returned value of EAX (Supports XSAVES/XRSTORS and IA32_XSS [1]), and then it reads the MSR IA32_VMX_PROCBASED_CTLS2 (index 0x48B) and looks at bit 20 (Enable XSAVES/XSTORS [2]). If CPUID shows that XSAVES is supported and the bit is not enabled in the MSR, Hyper-V decides to fail and stops its initialization. It used to work until last spring/summer where something might have changed in either KVM or QEMU. + +It seems that KVM sets the correct flags (in CPUID and the MSR) when the host CPU supports XSAVES. In QEMU, based on comments in target/i386/cpu.c it seems that XSAVES is not added in +builtin_x86_defs[].features[FEAT_VMX_SECONDARY_CTLS] because it might break live migration. Therefore, when setting the MSR for the vcpu, QEMU is masking off the feature. + +I have tested two possible solutions: +- adding the flag in .features[FEAT_VMX_SECONDARY_CTLS] +- removing the support of the instruction in feature_word_info[FEAT_XSAVE].feat_names + +Both solutions work and Hyper-v is happily running. I can provide a patch for the solution you might consider applying. Otherwise, is there a better way to fix the issue? + +Qemu version: 4.2.0 +Kernel version: 5.5.4 +Qemu command: https://gist.github.com/0xabe-io/b4d797538e2160252addc1d1d64738e2 + + +Many thanks, +Alexandre + +Ref: +[1] Intel SDM Volume 2A, chapter 3, page 196 +[2] Intel SDM Volume 3C, chapter 24, page 11 + +Are you using Libvirt? If so, you can just remove xsaves in the Libvirt XML ("<feature policy='disable' name='xsaves'/>">). + +It seems to me that this is a Hyper-V bug, but I understand that this is not a configuration that happens on real hardware. + +Adding the flag to all Skylake and newer systems (including Denverton and Snowridge) is the best choice, but we cannot just add it; if you want to send a patch, see the "Intel Atom Processor (SnowRidge)" model for an example of how to do it. + +Yes, I am using Libvirt and disabling the feature that way works, thank you! + +I can provide a patch. However I don't understand what you mean by: "but we cannot just add it". If you cannot add it, the patch will be rejected, right? + +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/118/none/1864704 b/results/classifier/118/none/1864704 new file mode 100644 index 00000000..1c5c3622 --- /dev/null +++ b/results/classifier/118/none/1864704 @@ -0,0 +1,82 @@ +peripherals: 0.726 +mistranslation: 0.713 +hypervisor: 0.644 +permissions: 0.569 +user-level: 0.563 +semantic: 0.563 +risc-v: 0.546 +assembly: 0.536 +performance: 0.531 +vnc: 0.526 +network: 0.524 +debug: 0.522 +TCG: 0.508 +architecture: 0.496 +ppc: 0.490 +register: 0.484 +graphic: 0.478 +VMM: 0.474 +arm: 0.464 +virtual: 0.454 +KVM: 0.453 +PID: 0.452 +device: 0.441 +kernel: 0.441 +files: 0.405 +x86: 0.364 +boot: 0.356 +socket: 0.326 +i386: 0.306 + +No compatible -machine option in qemu-system-ppc64 for e6500 core + +Hi, + +I'm trying to use qemu-system-ppc64 for emulating a QorIQ T2080 (with e6500 cores). +However, I couldn't find any -machine option that matches -cpu e6500 option, which are listed below: + +C:\Program Files\qemu>qemu-system-ppc64 -machine help +Supported machines are: +40p IBM RS/6000 7020 (40p) +bamboo bamboo +g3beige Heathrow based PowerMAC +mac99 Mac99 based PowerMAC +mpc8544ds mpc8544ds +none empty machine +powernv8 IBM PowerNV (Non-Virtualized) POWER8 +powernv IBM PowerNV (Non-Virtualized) POWER9 (alias of powernv9) +powernv9 IBM PowerNV (Non-Virtualized) POWER9 +ppce500 generic paravirt e500 platform +prep PowerPC PREP platform (deprecated) +pseries-2.1 pSeries Logical Partition (PAPR compliant) +pseries-2.10 pSeries Logical Partition (PAPR compliant) +pseries-2.11 pSeries Logical Partition (PAPR compliant) +pseries-2.12 pSeries Logical Partition (PAPR compliant) +pseries-2.12-sxxm pSeries Logical Partition (PAPR compliant) +pseries-2.2 pSeries Logical Partition (PAPR compliant) +pseries-2.3 pSeries Logical Partition (PAPR compliant) +pseries-2.4 pSeries Logical Partition (PAPR compliant) +pseries-2.5 pSeries Logical Partition (PAPR compliant) +pseries-2.6 pSeries Logical Partition (PAPR compliant) +pseries-2.7 pSeries Logical Partition (PAPR compliant) +pseries-2.8 pSeries Logical Partition (PAPR compliant) +pseries-2.9 pSeries Logical Partition (PAPR compliant) +pseries-3.0 pSeries Logical Partition (PAPR compliant) +pseries-3.1 pSeries Logical Partition (PAPR compliant) +pseries-4.0 pSeries Logical Partition (PAPR compliant) +pseries-4.1 pSeries Logical Partition (PAPR compliant) +pseries pSeries Logical Partition (PAPR compliant) (alias of pseries-4.2) +pseries-4.2 pSeries Logical Partition (PAPR compliant) (default) +ref405ep ref405ep +sam460ex aCube Sam460ex +taihu taihu +virtex-ml507 Xilinx Virtex ML507 reference design + +I am wondering if anyone knows that is if any of them can be selected for such emulation? Thank you! + +Try "-M ppce500 -cpu e6500" + +Thank you very much for your reply, Laurent. Does it mean that we can just use "-M ppce500 -cpu e6500" and for other options, there is no need to change? Is there any approach to verify this setup (for example, with a bare metal elf running in T2080)? Thanks again! + +You could try to build an image for this machine with buildroot (see https://buildroot.org/). Anyway, I'm closing this ticket now since this was not a bug. + diff --git a/results/classifier/118/none/1864814 b/results/classifier/118/none/1864814 new file mode 100644 index 00000000..d5dd5fe9 --- /dev/null +++ b/results/classifier/118/none/1864814 @@ -0,0 +1,65 @@ +device: 0.772 +user-level: 0.686 +virtual: 0.677 +performance: 0.630 +architecture: 0.596 +assembly: 0.587 +graphic: 0.572 +ppc: 0.502 +semantic: 0.461 +PID: 0.457 +register: 0.437 +vnc: 0.426 +files: 0.415 +socket: 0.402 +mistranslation: 0.394 +permissions: 0.386 +arm: 0.386 +boot: 0.360 +debug: 0.344 +risc-v: 0.331 +peripherals: 0.318 +hypervisor: 0.305 +VMM: 0.287 +network: 0.243 +TCG: 0.216 +kernel: 0.193 +KVM: 0.153 +x86: 0.121 +i386: 0.072 + +Improve UX for macOS when launching from a fullscreen app + +System/setup: +* MacBook Pro, macOS (any version from the last 2 years), external monitor. +* IDE on the laptop, emulator is used on the external monitor. + +Currently, when starting the emulator from e.g. Android Studio or IntelliJ IDEA, which is set to fullscreen mode on the laptop, which is like it's own virtual desktop (Space) in macOS, what happens is this: + +1. The virtual desktop (Space) on the laptop screen is switched because of #2. The reason is that only one window can be shown in Fullscreen this way. +2. The qemu splashscreen is shown for a few seconds, then it disappears. This is the reason for the virtual desktop switch. This splashscreen seems actually unnecessary to me, it has no value and it causes problems. +3. The actual emulator is shown, in my case on the external monitor (correctly). I guess if the splashscreen would not be shown, the virtual desktop switch would not happen, because the emulator would happen on the correct screen directly. + +So maybe the splashscreen and the emulator window should be the same window, so that the OS can remember it's position being the same as the emulator? +Or maybe the splash could be disabled (by default? otherwise an update to IDEs would be necessary for the improved behavior?) + +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. + + + +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/196 + + diff --git a/results/classifier/118/none/1865 b/results/classifier/118/none/1865 new file mode 100644 index 00000000..13331f8a --- /dev/null +++ b/results/classifier/118/none/1865 @@ -0,0 +1,54 @@ +graphic: 0.558 +debug: 0.513 +device: 0.497 +kernel: 0.495 +ppc: 0.410 +PID: 0.409 +mistranslation: 0.384 +network: 0.381 +user-level: 0.352 +socket: 0.308 +vnc: 0.292 +virtual: 0.288 +semantic: 0.280 +architecture: 0.270 +boot: 0.242 +hypervisor: 0.229 +permissions: 0.214 +VMM: 0.195 +risc-v: 0.195 +performance: 0.178 +assembly: 0.172 +peripherals: 0.172 +files: 0.132 +register: 0.130 +x86: 0.124 +arm: 0.114 +i386: 0.113 +TCG: 0.098 +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/118/none/1865188 b/results/classifier/118/none/1865188 new file mode 100644 index 00000000..d80a206e --- /dev/null +++ b/results/classifier/118/none/1865188 @@ -0,0 +1,71 @@ +device: 0.552 +user-level: 0.544 +mistranslation: 0.543 +performance: 0.532 +architecture: 0.527 +kernel: 0.521 +network: 0.499 +files: 0.486 +hypervisor: 0.480 +permissions: 0.460 +boot: 0.458 +PID: 0.456 +semantic: 0.446 +socket: 0.437 +graphic: 0.415 +peripherals: 0.415 +ppc: 0.407 +TCG: 0.405 +register: 0.379 +risc-v: 0.373 +arm: 0.367 +virtual: 0.357 +x86: 0.349 +vnc: 0.340 +VMM: 0.311 +i386: 0.309 +assembly: 0.308 +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/118/none/1865348 b/results/classifier/118/none/1865348 new file mode 100644 index 00000000..b22668d2 --- /dev/null +++ b/results/classifier/118/none/1865348 @@ -0,0 +1,78 @@ +device: 0.772 +files: 0.761 +graphic: 0.613 +semantic: 0.600 +kernel: 0.565 +ppc: 0.468 +architecture: 0.466 +PID: 0.443 +virtual: 0.423 +performance: 0.390 +hypervisor: 0.385 +x86: 0.337 +mistranslation: 0.311 +peripherals: 0.307 +network: 0.282 +permissions: 0.254 +socket: 0.228 +register: 0.217 +user-level: 0.216 +i386: 0.193 +vnc: 0.186 +debug: 0.169 +VMM: 0.169 +KVM: 0.125 +TCG: 0.119 +arm: 0.108 +assembly: 0.087 +risc-v: 0.076 +boot: 0.067 + +virsh domfsinfo testdom crashes the guest agent + + + +[@ ~]# virsh qemu-agent-command vps-01 '{"execute":"guest-get-fsinfo"}' + + +error: Guest agent is not responding: Guest agent disappeared while executing command + +[@ ~]# virsh domfsinfo vps-01 +error: Unable to get filesystem information +error: Guest agent is not responding: Guest agent disappeared while executing command + + +Fault bucket , type 0 +Event Name: APPCRASH +Response: Not available +Cab Id: 0 + +Problem signature: +P1: qemu-ga.exe +P2: 100.0.0.0 +P3: 5c473543 +P4: KERNELBASE.dll +P5: 6.1.7601.24545 +P6: 5e0eb6bd +P7: c0000005 +P8: 000000000000c4d2 +P9: +P10: + +Attached files: + +These files may be available here: +C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_qemu-ga.exe_bd2e6535bdb93328680e0285e89e08f2866db83_49df29e2 + +Analysis symbol: +Rechecking for solution: 0 +Report Id: 2ad29522-5bcc-11ea-bca6-525400e83365 +Report Status: 0 + + +guest os: windows server std 2008r2 + +Does this problem still reproduce with the latest versions of QEMU and libvirt? If so, could you please provide a backtrace of the crashed guest-agent? Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/none/1865350 b/results/classifier/118/none/1865350 new file mode 100644 index 00000000..5074bc1a --- /dev/null +++ b/results/classifier/118/none/1865350 @@ -0,0 +1,76 @@ +device: 0.797 +socket: 0.731 +graphic: 0.729 +PID: 0.728 +hypervisor: 0.722 +permissions: 0.692 +files: 0.675 +semantic: 0.675 +performance: 0.656 +vnc: 0.654 +architecture: 0.633 +risc-v: 0.622 +user-level: 0.618 +ppc: 0.617 +mistranslation: 0.601 +register: 0.586 +arm: 0.579 +peripherals: 0.548 +assembly: 0.526 +network: 0.462 +virtual: 0.442 +VMM: 0.427 +debug: 0.410 +kernel: 0.407 +boot: 0.385 +x86: 0.376 +i386: 0.336 +KVM: 0.248 +TCG: 0.243 + +fstrim not working with image mounted to path? + + +guest os: windows server standard 2016 +qemu agent version 100.0.0 + +os supports trimming +path mounted image does not support trimming + +C:\Users\Administrator>fsutil behavior query disabledeletenotify +NTFS DisableDeleteNotify = 0 +ReFS DisableDeleteNotify = 1 + + +[@ ~]# virsh qemu-agent-command vps-xxx '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"path":"C:\\"},{"path":"C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Mailbox\\xxxx\\","error":"The given volume path is invalid. (0x89000001)"}]}} + + +Looks like the fstrim does not like/check images mounted on a path? Nor detects if image trimming is supported. xxxx is a ReFS mounted image without trimming support. + +If I enable trimming on the ReFS image, and configure it win2016, the result is still the same. + + +C:\Users\Administrator>fsutil behavior query disabledeletenotify +NTFS DisableDeleteNotify = 0 +ReFS DisableDeleteNotify = 0 + +[root@c03 ~]# virsh qemu-agent-command vps-xxx '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"path":"C:\\"},{"path":"C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Mailbox\\xxxx\\","error":"The given volume path is invalid. (0x89000001)"}]}} + +PS. tried this on a win 2016 std server with just one fs, no problems then. + +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/118/none/1865626 b/results/classifier/118/none/1865626 new file mode 100644 index 00000000..233618cb --- /dev/null +++ b/results/classifier/118/none/1865626 @@ -0,0 +1,68 @@ +kernel: 0.788 +architecture: 0.752 +ppc: 0.587 +device: 0.585 +performance: 0.573 +boot: 0.552 +socket: 0.550 +PID: 0.481 +mistranslation: 0.412 +semantic: 0.399 +permissions: 0.346 +register: 0.304 +debug: 0.300 +user-level: 0.272 +graphic: 0.264 +peripherals: 0.251 +network: 0.245 +assembly: 0.232 +files: 0.216 +risc-v: 0.199 +vnc: 0.196 +virtual: 0.181 +arm: 0.181 +x86: 0.141 +i386: 0.124 +VMM: 0.088 +TCG: 0.078 +hypervisor: 0.069 +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/118/none/1867072 b/results/classifier/118/none/1867072 new file mode 100644 index 00000000..9ab7969c --- /dev/null +++ b/results/classifier/118/none/1867072 @@ -0,0 +1,106 @@ +mistranslation: 0.690 +architecture: 0.638 +arm: 0.502 +kernel: 0.418 +graphic: 0.395 +semantic: 0.304 +device: 0.297 +performance: 0.292 +peripherals: 0.257 +user-level: 0.254 +network: 0.239 +assembly: 0.212 +hypervisor: 0.197 +x86: 0.191 +register: 0.189 +socket: 0.185 +permissions: 0.180 +vnc: 0.175 +ppc: 0.175 +PID: 0.150 +debug: 0.141 +files: 0.131 +boot: 0.127 +KVM: 0.114 +VMM: 0.110 +risc-v: 0.105 +TCG: 0.098 +virtual: 0.097 +i386: 0.083 + +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/118/none/1868221 b/results/classifier/118/none/1868221 new file mode 100644 index 00000000..f4bf48e3 --- /dev/null +++ b/results/classifier/118/none/1868221 @@ -0,0 +1,93 @@ +socket: 0.425 +mistranslation: 0.409 +device: 0.407 +kernel: 0.399 +PID: 0.382 +semantic: 0.379 +files: 0.358 +permissions: 0.328 +ppc: 0.301 +register: 0.297 +network: 0.294 +architecture: 0.268 +hypervisor: 0.265 +boot: 0.257 +performance: 0.255 +graphic: 0.251 +user-level: 0.235 +debug: 0.196 +arm: 0.181 +peripherals: 0.179 +vnc: 0.176 +risc-v: 0.157 +i386: 0.127 +VMM: 0.126 +TCG: 0.103 +x86: 0.102 +KVM: 0.092 +assembly: 0.091 +virtual: 0.085 + +/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/118/none/1869006 b/results/classifier/118/none/1869006 new file mode 100644 index 00000000..c500fe1b --- /dev/null +++ b/results/classifier/118/none/1869006 @@ -0,0 +1,371 @@ +user-level: 0.599 +virtual: 0.572 +KVM: 0.533 +risc-v: 0.527 +device: 0.524 +TCG: 0.508 +architecture: 0.504 +mistranslation: 0.503 +register: 0.486 +boot: 0.485 +debug: 0.483 +arm: 0.480 +permissions: 0.472 +performance: 0.470 +graphic: 0.465 +assembly: 0.456 +PID: 0.452 +kernel: 0.451 +semantic: 0.445 +network: 0.443 +VMM: 0.442 +socket: 0.425 +files: 0.416 +i386: 0.412 +ppc: 0.410 +vnc: 0.379 +x86: 0.360 +hypervisor: 0.360 +peripherals: 0.359 + +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/118/none/1869426 b/results/classifier/118/none/1869426 new file mode 100644 index 00000000..e1e27b4a --- /dev/null +++ b/results/classifier/118/none/1869426 @@ -0,0 +1,114 @@ +register: 0.591 +device: 0.577 +permissions: 0.527 +PID: 0.470 +virtual: 0.458 +graphic: 0.454 +semantic: 0.427 +performance: 0.415 +peripherals: 0.410 +hypervisor: 0.407 +network: 0.406 +ppc: 0.406 +mistranslation: 0.398 +architecture: 0.392 +files: 0.390 +risc-v: 0.388 +VMM: 0.374 +arm: 0.369 +TCG: 0.358 +socket: 0.354 +boot: 0.342 +debug: 0.333 +user-level: 0.330 +vnc: 0.320 +assembly: 0.291 +KVM: 0.261 +kernel: 0.255 +x86: 0.140 +i386: 0.126 + +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 + + |