diff options
Diffstat (limited to 'results/classifier/gemma3:12b/hypervisor')
478 files changed, 18527 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/hypervisor/1011 b/results/classifier/gemma3:12b/hypervisor/1011 new file mode 100644 index 00000000..f1abe1c1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1011 @@ -0,0 +1,22 @@ + +hvf: RDTSCP capability not passed to guests +Description of problem: + +Steps to reproduce: +1. Run: +wget https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86/alpine-standard-3.15.4-x86.iso +./qemu-system-x86_64 -cpu host,+rdtscp -machine q35,accel=hvf -m 512 -cdrom ./alpine-standard-3.15.4-x86.iso + +2. login as "root" +3. type + +cat /etc/cpuinfo | grep rdtscp + +Expected result: cpu flag lines including rdtscp +Actual result: empty, with: + +warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27] +Additional information: +This patch apparently resolves the issue according to my tests: + +https://lore.kernel.org/qemu-devel/20211101054836.21471-1-dirty@apple.com/ diff --git a/results/classifier/gemma3:12b/hypervisor/1016 b/results/classifier/gemma3:12b/hypervisor/1016 new file mode 100644 index 00000000..26685501 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1016 @@ -0,0 +1,4 @@ + +In-process sandboxing of the majority of QEMU via WebAssembly or similar +Additional information: +This would be in addition to other sandboxes, such as sVirt. diff --git a/results/classifier/gemma3:12b/hypervisor/1017 b/results/classifier/gemma3:12b/hypervisor/1017 new file mode 100644 index 00000000..40713027 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1017 @@ -0,0 +1,14 @@ + +Qemu Windows 10 restart bluescreen +Description of problem: +after shutting down qemu VM box and open some system programs on Host System, getting Bluescreen +with following issue - Memory Manangement or shutting down you Host system, getting bluescreen. +Only after stoppingh using qemu vm reboot system. +Steps to reproduce: +1. start qemu vm, ty get some operations +1. then stop the qemu vm via console comands +1. rebooting or restarting Host system +1. by shutting down, you get Bluescreen +2. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1029 b/results/classifier/gemma3:12b/hypervisor/1029 new file mode 100644 index 00000000..81ef76ce --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1029 @@ -0,0 +1,54 @@ + +Unable to build qemu on macOS Monterey, M1 Pro +Description of problem: +qemu doesn't build, producing the following error: +``` +$ make +# snip +FAILED: libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o +cc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/opt/homebrew/Cellar/pixman/0.40.0/include/pixman-1 -I/opt/homebrew/Cellar/glib/2.72.1/include -I/opt/homebrew/Cellar/glib/2.72.1/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.72.1/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre/8.45/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -iquote . -iquote /Users/duncanbayne/code/qemu -iquote /Users/duncanbayne/code/qemu/include -iquote /Users/duncanbayne/code/qemu/disas/libvixl -iquote /Users/duncanbayne/code/qemu/tcg/aarch64 -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o -MF libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o.d -o libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o -c ../target/arm/hvf/hvf.c +../target/arm/hvf/hvf.c:586:15: error: unknown type name 'ARMCPRegInfo'; did you mean 'ARMCPUInfo'? + const ARMCPRegInfo *ri; + ^~~~~~~~~~~~ + ARMCPUInfo +../target/arm/cpu-qom.h:38:3: note: 'ARMCPUInfo' declared here +} ARMCPUInfo; + ^ +../target/arm/hvf/hvf.c:589:14: error: implicit declaration of function 'get_arm_cp_reginfo' is invalid in C99 [-Werror,-Wimplicit-function-declaration] + ri = get_arm_cp_reginfo(arm_cpu->cp_regs, key); + ^ +../target/arm/hvf/hvf.c:589:12: warning: incompatible integer to pointer conversion assigning to 'const ARMCPUInfo *' (aka 'const struct ARMCPUInfo *') from 'int' [-Wint-conversion] + ri = get_arm_cp_reginfo(arm_cpu->cp_regs, key); + ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../target/arm/hvf/hvf.c:591:26: error: no member named 'type' in 'struct ARMCPUInfo' + assert(!(ri->type & ARM_CP_NO_RAW)); + ~~ ^ +/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/assert.h:99:25: note: expanded from macro 'assert' + (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __ASSERT_FILE_NAME, __LINE__, #e) : (void)0) + ^ +../target/arm/hvf/hvf.c:591:33: error: use of undeclared identifier 'ARM_CP_NO_RAW' + assert(!(ri->type & ARM_CP_NO_RAW)); + ^ +1 warning and 4 errors generated. +ninja: build stopped: subcommand failed. +make[1]: *** [run-ninja] Error 1 +make: *** [all] Error 2 +``` +Steps to reproduce: +``` +git clone https://gitlab.com/qemu-project/qemu.git +cd qemu +./configure +make +``` +Additional information: +``` +$ cc --version +Apple clang version 13.1.6 (clang-1316.0.21.2.5) +Target: arm64-apple-darwin21.4.0 +Thread model: posix +InstalledDir: /Library/Developer/CommandLineTools/usr/bin + +$ ninja --version +1.10.2.git.kitware.jobserver-1 +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1031 b/results/classifier/gemma3:12b/hypervisor/1031 new file mode 100644 index 00000000..66e28a10 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1031 @@ -0,0 +1,43 @@ + +Intel 12th Gen CPU not working with QEMU Hyper-V nested virtualization +Description of problem: +When booting with Hyper-V + host-passthrough it gets stuck at tianocore, does not change until I reboot which then loops into windows diagnostics which leads nowhere. Done using Windows 10, tried using newest windows version and 1909. + +Specs: Manjaro Gnome 5.15 LTS, i5-12600k, z690 gigabyte aorus elite ddr4, rtx 3070ti. + +I’ve spent days trying to figure out what was messing with it and it turned out I could boot when messing with my CPU topology, for some reason my 12th gen + Hyper-V + host-passthrough only works with sockets. Cores and threads above 1 causes boot problems, apart from disabling vme which boots, but the hypervisor does not load. + +This fails (normal host-passthrough): +``` + <cpu mode="host-passthrough" check="none" migratable="on"> + <topology sockets="1" dies="1" cores="6" threads="2"/> + </cpu> +``` + +This boots (-can only change sockets): +``` + <cpu mode="host-passthrough" check="none" migratable="on"> + <topology sockets="12" dies="1" cores="1" threads="1"/> + </cpu> +``` + +This boots (-no hypervisor): +``` +<cpu mode="host-passthrough" check="partial" migratable="off"> + <topology sockets="1" dies="1" cores="6" threads="2"/> + <feature policy="disable" name="vme"/> + </cpu> +``` + +No matter what adjustment I do I cannot change the cores or threads or it will result in a boot failure, host-model just does not work once I boot the machine the host model changes to cooperlake. + +My current way of bypassing this is I’ve downloaded the QEMU source code, gone through cpu.c and modified the default skylake-client CPU model to match my CPU, then I added in most of my i5-12600k flags manually, this seems to work with a 35-45% performance drop in CPU and in ram. Without Hyper-V enabled and using the normal host-passthrough I get near bare metal performance. + +Tried with multiple versions of QEMU, EDK2, and loads of kernel versions (to add to this my i5-12600k gen does not work on kernel version 5.13 and below) even went ahead to try Ubuntu and had the same problem, my other (i7-9700k) PC works fine with Hyper-V. Also disabled my E-cores through bios resulting in the same issue. CPU pinning the P-cores to the guest does not seem to help. +Steps to reproduce: +1. Enable hyper-v in windows features +2. Restart guest +3. Boot failure +Additional information: +Hyper-V host-passthrough XML: +https://pst.klgrth.io/paste/yc5wk diff --git a/results/classifier/gemma3:12b/hypervisor/1033 b/results/classifier/gemma3:12b/hypervisor/1033 new file mode 100644 index 00000000..e73a658a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1033 @@ -0,0 +1,28 @@ + +fakeroot under qemu fails with 'semop(1): encountered an error: Function not implemented' +Description of problem: +Appears to be the same issue as that discussed and reportedly fixed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965109 + +Running raspberry pi os in a chroot (using schroot). Execution of fakeroot as part of dpkg-buildpackage results in: + +``` +dpkg-buildpackage: info: source package clementine +dpkg-buildpackage: info: source version 1.4.0rc1-836-g4665916ba~bullseye +dpkg-buildpackage: info: source distribution bullseye +dpkg-buildpackage: info: source changed by David Sansome <me@davidsansome.com> +dpkg-buildpackage: info: host architecture armhf + dpkg-source --before-build . + fakeroot debian/rules clean +semop(1): encountered an error: Function not implemented +dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 1 +``` + +This is the same error as reported in bug 965109, but I'm running the most recent version of qemu - I built it from the git repo, so it should include the fix for 965109. +Steps to reproduce: +1. Setup (s)chroot with arm architecture (although the architecture may not matter) +2. Run fakeroot in the chroot +3. Observe the failure related to the semop syscall +Additional information: +- Not sure what other information I can provide to be helpful. +- The command line listed above is what I gather from ps; it's how qemu-arm-static is called by schroot. I've not been able to figure out _how_ schroot calls qemu-arm-static, I only know it does. +- I compiled qemu from source using my own user id, and ran into an issue with make install, so I manually used install to deploy the executable to /usr/local/bin... And then had to symlink that to /usr/bin as schroot apparently hardcodes the location of qemu-arm-static (at least it did not pick up the version I'd placed in /usr/local/bin). diff --git a/results/classifier/gemma3:12b/hypervisor/1038 b/results/classifier/gemma3:12b/hypervisor/1038 new file mode 100644 index 00000000..b92aebe9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1038 @@ -0,0 +1,12 @@ + +ppc 'max' CPU model is unlike the other targets 'max' CPU model +Description of problem: +On most targets the 'max' CPU model is either equivalent to 'host' (for KVM) or equivalent to all available CPU features (for TCG). + +On PPC64, however, this is not the case. Instead the 'max' model is an alias of the old '7400_v2.9' and simply doesn't work. + +This is confusing. At the very least the 'max' model alias should be deleted. Ideally a proper replacement would be introduced that matches semantics on other arches. +Steps to reproduce: +1. qemu-system-ppc64 -cpu max + +should be equiv to '-cpu host' or should expose all TCG features. diff --git a/results/classifier/gemma3:12b/hypervisor/1040 b/results/classifier/gemma3:12b/hypervisor/1040 new file mode 100644 index 00000000..bdc9f39e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1040 @@ -0,0 +1,7 @@ + +Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs in it during the freeze +Description of problem: +Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs inside VM during the freeze. Timestamp of the last log written into journal is right before the freeze and the pretty next log is right after the freeze is gone. Looks like "black hole". No ping from from the host toward the VM. There is no way to connect to the VM even via spice on virt-manager as well. Seems like the VM is suspending. Htop on the host during the time of the freeze shows 100% load of all eight cores dedicated to the VM. But the host system is available and reachable, the lxc's inside this host is available and reachable as well. + + + diff --git a/results/classifier/gemma3:12b/hypervisor/1042 b/results/classifier/gemma3:12b/hypervisor/1042 new file mode 100644 index 00000000..b572f599 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1042 @@ -0,0 +1,21 @@ + +windows 10 guest freezes the host on shutdown +Description of problem: +Windows 10 guest sometimes freezes the QEMU host when shutting down. + +There has been a bug reported about this in the past here: +https://bugs.launchpad.net/qemu/+bug/1580459 + +I am also using PCI Passthrough with an NVIDIA GPU. +Some users have claimed to have fixed this issue by enabling Message Signaled-based Interrupts-mode on the PCI Devices the (GPU/HDMI-AUDIO). I have have these enabled and confirmed they are enabled, but the issue still persists. + +This bug has been effecting me for over a year, I just never bothered to look deeper into it after I seen the issue still persists after enabling the MSI stuff. + +There is something I noticed about this issue. Basically, it appears that I can mostly avoid the issue entirely, by making sure that as the guest is shutting down, that I move the mouse a bit. +The host almost never freezes if I do this, and only happens very rarely. +But if I start a shutdown, and just don't move the mouse at all, it is very likely the host will lock up, requiring a complete reboot. I am pretty sure the mouse movement, should be a big clue, because I can consistently reproduce the issue. The issue itself does not (atleast) for me appear to be tied to how long the VM is running or if gaming on it or not, though I have not thoroughly tested this. + +I have gone through various kernel/qemu/libvirt updates, the issue occurs in all of them, and has been an issue from the very beginning of my setup. +Steps to reproduce: +1. Start Windows 10 guest. +2. Shutdown Windows 10 guest diff --git a/results/classifier/gemma3:12b/hypervisor/1043 b/results/classifier/gemma3:12b/hypervisor/1043 new file mode 100644 index 00000000..a87eb9a5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1043 @@ -0,0 +1,11 @@ + +QEMU cpu max doesnot work on Windows 11 with ryzen processor and whpx +Description of problem: +- System does not boot. +- WHPX: setting APIC emulation mode in the hypervisor +- Windows Hypervisor Platform accelerator is operational +- whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005) +- qemu: WHPX: Unexpected VP exit code 4 +Steps to reproduce: +1. Windows 11 / Ryzen +2. qemu-system-x86_64.exe --accel whpx --cpu max diff --git a/results/classifier/gemma3:12b/hypervisor/1052 b/results/classifier/gemma3:12b/hypervisor/1052 new file mode 100644 index 00000000..f1227a91 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1052 @@ -0,0 +1,80 @@ + +QEMU monitor hangs after "stop" QMP command called in postcopy-paused migration state +Description of problem: +QEMU monitor hangs when I try to pause virtual CPUs using "stop" QMP command +on the destination host once migration enters postcopy-paused (after it was +paused using "migrate-pause" QMP command on the source host). QEMU just does +not send any reply to the "stop" command. +Steps to reproduce: +1. start migration +2. wait for the first iteration to finish +3. switch to post-copy using "migrate-start-postcopy" +3. break migration with "migrate-pause" +4. send "stop" to the destination monitor +Additional information: +Unfortunately I haven't been able to get a stack trace as gdb just hangs when +I try to attach it to QEMU after step 4. I can see threads getting SIGUSR1 +after the "stop" command, but I cannot get to gdb prompt afterwards: + +``` +(gdb) c +Continuing. +[New Thread 0x7f41ec9be640 (LWP 1112)] +[New Thread 0x7f41d7fff640 (LWP 1113)] +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +``` + +I was able to attach strace to it though (in case it is at least a bit +useful). The first line corresponds to the final '}' of the +{"execute":"stop","id":"libvirt-413"} QMP comamnd: + +``` +[pid 72970] recvmsg(20, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="}", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 1 +[pid 72970] write(4, "\1\0\0\0\0\0\0\0", 8) = 8 +[pid 72949] <... ppoll resumed>) = 1 ([{fd=4, revents=POLLIN}], left {tv_sec=0, tv_nsec=513181335}) +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] read(4, <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... read resumed>"\1\0\0\0\0\0\0\0", 512) = 8 +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}, {fd=46, events=POLLIN}, {fd=47, events=POLLIN}, {fd=48, events=POLLIN}, {fd=49, events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=POLLIN}, {fd=52, events=POLLIN}, {fd=53, events=POLLIN}, {fd=54, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, ...], 74, {tv_sec=0, tv_nsec=0}, NULL, 8 <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... ppoll resumed>) = 0 (Timeout) +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] write(8, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... write resumed>) = 8 +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}, {fd=46, events=POLLIN}, {fd=47, events=POLLIN}, {fd=48, events=POLLIN}, {fd=49, events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=POLLIN}, {fd=52, events=POLLIN}, {fd=53, events=POLLIN}, {fd=54, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, ...], 74, {tv_sec=0, tv_nsec=0}, NULL, 8 <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... ppoll resumed>) = 1 ([{fd=8, revents=POLLIN}], left {tv_sec=0, tv_nsec=0}) +[pid 72970] poll([{fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=0}], 3, -1 <unfinished ...> +[pid 72949] rt_sigprocmask(SIG_BLOCK, ~[], <unfinished ...> +[pid 72970] <... poll resumed>) = 1 ([{fd=19, revents=POLLIN}]) +[pid 72949] <... rt_sigprocmask resumed>[BUS USR1 ALRM IO], 8) = 0 +[pid 72970] read(19, <unfinished ...> +[pid 72949] getpid() = 72949 +[pid 72970] <... read resumed>"\5\0\0\0\0\0\0\0", 16) = 8 +[pid 72949] tgkill(72949, 72971, SIGUSR1 <unfinished ...> +[pid 72970] poll([{fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=0}], 3, -1 <unfinished ...> +[pid 72949] <... tgkill resumed>) = 0 +[pid 72949] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0 +[pid 72949] rt_sigprocmask(SIG_BLOCK, ~[], [BUS USR1 ALRM IO], 8) = 0 +[pid 72949] getpid() = 72949 +[pid 72949] tgkill(72949, 72972, SIGUSR1) = 0 +[pid 72949] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0 +[pid 72949] futex(0x5606f6cb73a8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY +``` + +And that's it, the last futex never returns. diff --git a/results/classifier/gemma3:12b/hypervisor/1057 b/results/classifier/gemma3:12b/hypervisor/1057 new file mode 100644 index 00000000..975d0b0b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1057 @@ -0,0 +1,24 @@ + +AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions +Description of problem: +I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction: +`0x0000000000000000: C3 44 00 B8 str w3, [x6], #4` + +notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting. + +Here is the relevant part of the manual: + +``` +For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts: +• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback). +``` + +However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions. + +Another example of instruction: `0x00000000000002f8: 01 1C 40 38 ldrb w1, [x0, #1]!` +Steps to reproduce: +1. Run some hypervisor in EL2 +2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP) +3. Observe the value of ESR_EL2 on data abort + +Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch. diff --git a/results/classifier/gemma3:12b/hypervisor/1065 b/results/classifier/gemma3:12b/hypervisor/1065 new file mode 100644 index 00000000..59be2869 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1065 @@ -0,0 +1,6 @@ + +cputlb: uninitialized local variable in tlb_set_page_with_attrs cause SIGSEGV when a CPU access an unmapped IOMMU page +Description of problem: +When a TCG cpu accesses an unmapped page within an IOMMU region that causes a translation fault, QEMU SIGSEGVs in `io_readx`. +The reason was that in `address_space_translate_for_iotlb`, `xlat` is not set on a permission fault. +As a result, `xlat` in `tlb_set_page_with_attr` is uninitialized. This in turn causes various mis-calculation and eventually crashes in `io_readx`. diff --git a/results/classifier/gemma3:12b/hypervisor/1073 b/results/classifier/gemma3:12b/hypervisor/1073 new file mode 100644 index 00000000..c5dae0a9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1073 @@ -0,0 +1,30 @@ + +SIGABRT with -M raspi3b,accel=hvf on macOS +Description of problem: +There is a `SIGUSR2` or `SIGUSR1` raised which causes QEMU to abort: +``` +(lldb) bt +* thread #3, stop reason = signal SIGUSR2 + * frame #0: 0x0000000184c384a4 libsystem_kernel.dylib`__sigsuspend + 8 + frame #1: 0x0000000100b7ff34 qemu-system-aarch64`qemu_coroutine_new at coroutine-sigaltstack.c:221:9 + frame #2: 0x0000000100b91f0c qemu-system-aarch64`qemu_coroutine_create(entry=(qemu-system-aarch64`monitor_qmp_dispatcher_co at qmp.c:211), opaque=0x0000000000000000) at qemu-coroutine.c:90:14 + frame #3: 0x0000000100a833d8 qemu-system-aarch64`monitor_init_globals_core at monitor.c:707:25 +``` + +I tried skipping over it with `lldb`: +``` +(lldb) b main +(lldb) r +(lldb) process handle SIGUSR1 -s false -p true +(lldb) process handle SIGUSR2 -s false -p true +(lldb) c +qemu-system-aarch64: Unknown Error +``` + +I investigated the Unknown Error and and it's actually `HV_ILLEGAL_GUEST_STATE` which is unhandled in the `assert_hvf_ok` function. From here the VM will fail. +Steps to reproduce: +1. Get a fake disk. Or create a fake one with: `qemu-img create -f qcow2 zero.qcow2 2G` +2. Run QEMU with the HVF accelerator: `qemu-system-aarch64 -M raspi3b,accel=hvf -drive id=card0,if=none,format=qcow2,index=0,file=./zero.qcow2 -device sd-card,drive=card0 -serial stdio +` +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1075 b/results/classifier/gemma3:12b/hypervisor/1075 new file mode 100644 index 00000000..eafaaa05 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1075 @@ -0,0 +1,17 @@ + +Unable to create a cluster using ppc64le specific kind binary on x86 host architecture +Description of problem: + +Steps to reproduce: +1. docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +2. wget https://github.com/kubernetes-sigs/kind/releases/download/v0.14.0/kind-linux-ppc64le +3. chmod u+x kind-linux-ppc64le +4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/ppc64le/kubectl +5. chmod +x kubectl +6. sudo cp kubectl /usr/local/bin/ +7. KUBECONFIG="${HOME}/kind-test-config" +8. export KUBECONFIG +9. ./kind-linux-ppc64le create cluster --image quay.io/mayurwaghmode111/node-ppc64le:ppc64le -v=3 --wait 1m --retain +10. ./kind-linux-ppc64le export logs +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1077 b/results/classifier/gemma3:12b/hypervisor/1077 new file mode 100644 index 00000000..00b3b81a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1077 @@ -0,0 +1,2 @@ + +Qemu - Can't connect to ESXi guest diff --git a/results/classifier/gemma3:12b/hypervisor/1077514 b/results/classifier/gemma3:12b/hypervisor/1077514 new file mode 100644 index 00000000..486c04d4 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1077514 @@ -0,0 +1,91 @@ + +*** buffer overflow detected ***: qemu-system-x86_64 terminated with nowait enabled + +qemu-system-x86_64 -m 1024 -nographic -cpu coreduo -icount auto -hdachs 980,16,32 -kernel asa842-vmlinuz -initrd asa842-initrd.gz -append "ide_generic.probe_mask=0x01 ide_core.chs=0.0:980,16,32 auto nousb console=ttyS0,9600 bigphysarea=65536 no-hlt" -net nic -serial telnet::3020,server,nowait +failed to initialize KVM: Device or resource busy +Back to tcg accelerator. +QEMU 1.2.0 monitor - type 'help' for more information +(qemu) Warning: vlan 0 is not connected to host network +*** buffer overflow detected ***: qemu-system-x86_64 terminated +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fd9f04b882c] +/lib/x86_64-linux-gnu/libc.so.6(+0x109700)[0x7fd9f04b7700] +/lib/x86_64-linux-gnu/libc.so.6(+0x10a7be)[0x7fd9f04b87be] +qemu-system-x86_64(+0xf1b5d)[0x7fd9f4bb1b5d] +qemu-system-x86_64(+0x18f148)[0x7fd9f4c4f148] +qemu-system-x86_64(main+0xfe3)[0x7fd9f4b35353] +/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fd9f03cf76d] +qemu-system-x86_64(+0x796e9)[0x7fd9f4b396e9] +======= Memory map: ======== +40f54000-50f54000 rwxp 00000000 00:00 0 +7fd990000000-7fd990029000 rw-p 00000000 00:00 0 +7fd990029000-7fd994000000 ---p 00000000 00:00 0 +7fd995907000-7fd995a34000 rw-p 00000000 00:00 0 +7fd995a34000-7fd995a76000 rw-p 00000000 00:00 0 +7fd995a76000-7fd995c00000 rw-p 00000000 00:00 0 +7fd995c00000-7fd996c00000 rw-p 00000000 00:00 0 +7fd996c00000-7fd99842c000 rw-p 00000000 00:00 0 +7fd99842d000-7fd99842e000 rw-p 00000000 00:00 0 +7fd99842e000-7fd99844e000 rw-p 00000000 00:00 0 +7fd99844e000-7fd998450000 rw-p 00000000 00:00 0 +7fd998450000-7fd998470000 rw-p 00000000 00:00 0 +7fd998470000-7fd998472000 rw-p 00000000 00:00 0 +7fd998472000-7fd998492000 rw-p 00000000 00:00 0 +7fd998492000-7fd998493000 rw-p 00000000 00:00 0 +7fd998493000-7fd998494000 ---p 00000000 00:00 0 +7fd998494000-7fd998d95000 rw-p 00000000 00:00 0 [stack:4808] +7fd998dd6000-7fd998e00000 rw-p 00000000 00:00 0 +7fd998e00000-7fd9d8e00000 rw-p 00000000 00:00 0 +7fd9d8e00000-7fd9d8fd7000 rw-p 00000000 00:00 0 +7fd9d8fd7000-7fd9d8fd8000 ---p 00000000 00:00 0 +7fd9d8fd8000-7fd9e87d9000 rw-p 00000000 00:00 0 [stack:4807] +7fd9e87d9000-7fd9e87e2000 r-xp 00000000 08:05 1577354 /lib/x86_64-linux-gnu/libcrypt-2.15.so +7fd9e87e2000-7fd9e89e2000 ---p 00009000 08:05 1577354 /lib/x86_64-linux-gnu/libcrypt-2.15.so +7fd9e89e2000-7fd9e89e3000 r--p 00009000 08:05 1577354 /lib/x86_64-linux-gnu/libcrypt-2.15.so +7fd9e89e3000-7fd9e89e4000 rw-p 0000a000 08:05 1577354 /lib/x86_64-linux-gnu/libcrypt-2.15.so +7fd9e89e4000-7fd9e8a12000 rw-p 00000000 00:00 0 +7fd9e8a12000-7fd9e8ab7000 r-xp 00000000 08:05 4341908 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 +7fd9e8ab7000-7fd9e8cb7000 ---p 000a5000 08:05 4341908 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 +7fd9e8cb7000-7fd9e8cb9000 r--p 000a5000 08:05 4341908 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 +7fd9e8cb9000-7fd9e8cbb000 rw-p 000a7000 08:05 4341908 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 +7fd9e8cbb000-7fd9e8cbc000 rw-p 00000000 00:00 0 +7fd9e8cbc000-7fd9e8d00000 r-xp 00000000 08:05 4341652 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 +7fd9e8d00000-7fd9e8f00000 ---p 00044000 08:05 4341652 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 +7fd9e8f00000-7fd9e8f02000 r--p 00044000 08:05 4341652 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 +7fd9e8f02000-7fd9e8f04000 rw-p 00046000 08:05 4341652 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 +7fd9e8f04000-7fd9e8f11000 r-xp 00000000 08:05 4341646 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 +7fd9e8f11000-7fd9e9110000 ---p 0000d000 08:05 4341646 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 +7fd9e9110000-7fd9e9111000 r--p 0000c000 08:05 4341646 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 +7fd9e9111000-7fd9e9112000 rw-p 0000d000 08:05 4341646 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 +7fd9e9112000-7fd9e913a000 r-xp 00000000 08:05 4341985 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 +7fd9e913a000-7fd9e9339000 ---p 00028000 08:05 4341985 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 +7fd9e9339000-7fd9e933a000 r--p 00027000 08:05 4341985 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 +7fd9e933a000-7fd9e933b000 rw-p 00028000 08:05 4341985 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 +7fd9e933b000-7fd9e933c000 rw-p 00000000 00:00 0 +7fd9e933c000-7fd9e9342000 r-xp 00000000 08:05 4341777 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.0 +7fd9e9342000-7fd9e9541000 ---p 00006000 08:05 4341777 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.0 +7fd9e9541000-7fd9e9542000 r--p 00005000 08:05 4341777 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.0 +7fd9e9542000-7fd9e9543000 rw-p 00006000 08:05 4341777 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.0 +7fd9e9543000-7fd9e956e000 r-xp 00000000 08:05 4341974 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7fd9e956e000-7fd9e976e000 ---p 0002b000 08:05 4341974 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7fd9e976e000-7fd9e976f000 r--p 0002b000 08:05 4341974 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7fd9e976f000-7fd9e9770000 rw-p 0002c000 08:05 4341974 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7fd9e9770000-7fd9e9a23000 r-xp 00000000 08:05 4341976 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7fd9e9a23000-7fd9e9c22000 ---p 002b3000 08:05 4341976 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7fd9e9c22000-7fd9e9c3e000 r--p 002b2000 08:05 4341976 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7fd9e9c3e000-7fd9e9c3f000 rw-p 002ce000 08:05 4341976 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7fd9e9c3f000-7fd9e9c89000 r-xp 00000000 08:05 4336879 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7fd9e9c89000-7fd9e9e89000 ---p 0004a000 08:05 4336879 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7fd9e9e89000-7fd9e9e8a000 r--p 0004a000 08:05 4336879 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7fd9e9e8a000-7fd9e9e8b000 rw-p 0004b000 08:05 4336879 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7fd9e9e8b000-7fd9e9ea2000 r-xp 00000000 08:05 1577610 /lib/x86_64-linux-gnu/libnsl-2.15.so +7fd9e9ea2000-7fd9ea0a1000 ---p 00017000 08:05 1577610 /lib/x86_64-linux-gnu/libnsl-2.15.so +7fd9ea0a1000-7fd9ea0a2000 r--p 00016000 08:05 1577610 /lib/x86_64-linux-gnu/libnsl-2.15.so +7fd9ea0a2000-7fd9ea0a3000 rw-p 00017000 08:05 1577610 /lib/x86_64-linux-gnu/libnsl-2.15.so +7fd9ea0a3000-7fd9ea0a6000 rw-p 00000000 00:00 0 +7fd9ea0a6000-7fd9ea0a8000 r-xp 00000000 08:05 1579638 /lib/x86_64-linux-gnu/libkeyutils.so.1.4 +7fd9ea0a8000-7fd9ea2a8000 ---p 00002000 08:05 1579638 /lib/x86_64-linux-gnu/libkeyutils.so.1.4 +7fd9ea2a8000-7fd9ea2a9000 r--p 00002000 08:05 1579638 /lib/x86_64-linux-gnu/libkeyutils.so.1.4 +7fd9ea2a9000-7fd9ea2aa000 rw-p 00003000 08:05 1579638 /lib/x86_64-linux-gnu/libkeyutils.so.1.4Afbrudt (SIGABRT) (core dumped) + +this only happens with "nowait" enabled. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1077806 b/results/classifier/gemma3:12b/hypervisor/1077806 new file mode 100644 index 00000000..44ce0d20 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1077806 @@ -0,0 +1,8 @@ + +Integrate Virtualbox/Qemu Guest booting as a desktop environment listing (request) + +I had seen this new way to install Chromium OS and "boot" it using LightDM's session select menu, and it made me think of an idea: + +What if you were able to boot virtual machines in the same manner? It would simplify the Ubuntu user's life GREATLY if they had easy access to a Windows VM that can synchronize their files to and fro (Guest additions) and not require a reboot to use it. Modern computers have more than enough power to do something like this, and it should be even easier if the system is using a dedicated virtual machine environment rather than a full blown desktop. + +I think this would make using Ubuntu a LOT less of a hassle for the new user who came from Windows :) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1078892 b/results/classifier/gemma3:12b/hypervisor/1078892 new file mode 100644 index 00000000..31d1a57f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1078892 @@ -0,0 +1,6 @@ + +qemu doesn't general protection fault if there are reserved bits set in page-directory-pointer table entries + +While working on implementing 32-bit PAE mode in a custom operating system, which I was testing in QEMU, I noticed that my OS worked correctly, but resulted in a general protection fault when booted on VMware, VirtualBox, or bochs. + +According to the Intel Architecture Manual, Volume 3A, Section 4.4.1 "PDPTE Registers", "If any of the PDPTEs sets both the P flag (bit 0) and any reserved bit, the MOV to CR instruction causes a general-protection exception (#GP(0)) and the PDPTEs are not loaded." QEMU does not emulate this behavior. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1079 b/results/classifier/gemma3:12b/hypervisor/1079 new file mode 100644 index 00000000..47a22ee7 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1079 @@ -0,0 +1,33 @@ + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Description of problem: +I am trying to build `arm64` image on my `x86_64` machine using `buildx` and I have encountered `qemu: uncaught target signal 11 (Segmentation fault) - core dumped` Error. <br> +# +Steps to reproduce: +1. Create a Dockerfile +``` +FROM python:3.8-slim + +ENV PYTHONDONTWRITEBYTECODE=1 + +# Install packages +RUN apt update +RUN apt-get install -y python3-pip +``` +2. Run binfmt container +``` +docker run --privileged --rm tonistiigi/binfmt --install all +``` +3. Setup new builder +``` +$ docker buildx create --name mybuilder +$ docker buildx use mybuilder +$ docker buildx inspect --bootstrap +``` +4. Build Image +``` +$ docker buildx build --platform linux/amd64,linux/arm64 --push -t user/failure-case . +``` +# +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1084 b/results/classifier/gemma3:12b/hypervisor/1084 new file mode 100644 index 00000000..4024bfbc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1084 @@ -0,0 +1,2 @@ + +Qemu - VCPU shutdown request error diff --git a/results/classifier/gemma3:12b/hypervisor/1125 b/results/classifier/gemma3:12b/hypervisor/1125 new file mode 100644 index 00000000..8568cfa9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1125 @@ -0,0 +1,4 @@ + +error on run qemu-system-aarch64 -smp 2 +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1137 b/results/classifier/gemma3:12b/hypervisor/1137 new file mode 100644 index 00000000..593ca121 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1137 @@ -0,0 +1,36 @@ + +When using qemu-system-x86_64 whpx acceleration, cpu information is set strangely. +Description of problem: +When using the guest with whpx acceleration in qemu-system-x86_64, the CPU information of the guest seems to be set strangely. + +When the guest is Linux, it seems that individual CPUs are allocated as many as the number of cores when using the -accel whpx option and the -smp option. +* -smp 4, -smp cores=4, -smp sockes=1, cores=4, threads=1 are all set to have 4 single-core CPUs plugged in + +If the guest is Windows, check the information with CPU-Z + It is recognized as a Pentium 4 and is displayed as a CPU with 1 core and n threads. + +Physically, it seems to be set to have n individual CPUs with 1 core plugged in. +In Windows 11 Home (which seems to be the case for all versions of Windows Home), you cannot give the -smp value more than 5. +* When booting with the -smp option value of 5 or more, a BSOD saying multiprocessor configuration not supported appears. -smp n, -smp cores=n, -smp sockes=1,cores=n,threads=1 All same symptoms occur +Steps to reproduce: +1. Boot Windows or Linux with -accel whpx -smp 4 option (or with the -accel whpx -smp sockets=1,cores=4,threads=1 option to make it deterministic) +2. For Linux guest, use cat /proc/cpuinfo to check cpu information, for Windows guest, use cpu-z, device manager, task manager, etc. to check cpu information +3. In the information of the Linux guest, it is displayed as fixed as core id : 0, cpu cores : 1, + In Windows guest, information is displayed as written in "Description of problem" respectively. +Additional information: +**Windows 11 Home Guest set to 4 cores :** + +qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx + + + +**Windows 11 Home Guest set to 5 cores :** + +qemu-system-x86_64 -M q35 -smp sockets=1,cores=5,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx + + + +**Linux (Debian 11) guest set to 4 cores :** + +qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 4g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="debian.vdi",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx + diff --git a/results/classifier/gemma3:12b/hypervisor/115 b/results/classifier/gemma3:12b/hypervisor/115 new file mode 100644 index 00000000..2d7000ab --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/115 @@ -0,0 +1,2 @@ + +shmat fails on 32-to-64 setup diff --git a/results/classifier/gemma3:12b/hypervisor/1152 b/results/classifier/gemma3:12b/hypervisor/1152 new file mode 100644 index 00000000..e449acec --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1152 @@ -0,0 +1,29 @@ + +Windows crashes on resuming from sleep if hv-tlbflush is enabled +Description of problem: +The above steps cause my Windows VM to BSOD immediately upon waking up (even before restarting the display driver in my case). +Steps to reproduce: +1. Boot Windows +2. Tell Windows to go to sleep (observe that qemu's state switches to suspended) +3. Cause windows to wake up (e.g. using the `system_wakeup` HMP command) +Additional information: +Looking at the crash dumps always shows the "ATTEMPTED WRITE TO READONLY MEMORY" error, and always with this stack trace: + +``` +nt!KeBugCheckEx +nt!MiRaisedIrqlFault+0x1413a6 +nt!MmAccessFault+0x4ef +nt!KiPageFault+0x35e +nt!MiIncreaseUsedPtesCount+0x12 +nt!MiBuildForkPte+0xc6 +nt!MiCloneVads+0x4ab +nt!MiCloneProcessAddressSpace+0x261 +nt!MmInitializeProcessAddressSpace+0x1cb631 +nt!PspAllocateProcess+0x1d13 +nt!PspCreateProcess+0x242 +nt!NtCreateProcessEx+0x85 +nt!KiSystemServiceCopyEnd+0x25 +ntdll!NtCreateProcessEx+0x14 +``` + +However, the process that is being created here is always `WerFault.exe`, i.e. the crash reporter. The crashing process is seemingly random. Removing `hv-tlbflush` from the command line resolves the problem. Hence, my hypothesis is that due to improper TLB flushing during wakeup, a random application on the core will crash, which spawns `WerFault.exe` which then immediately crashes again inside the kernel (also because of bad/stale TLB contents) and causes the BSOD. Perhaps one core wakes up first, requests a TLB flush, which is then *not* propagated to sleeping cores due to hv-tlbflush. Then one of those cores wakes up without the TLB flush? diff --git a/results/classifier/gemma3:12b/hypervisor/1153 b/results/classifier/gemma3:12b/hypervisor/1153 new file mode 100644 index 00000000..680e9ca6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1153 @@ -0,0 +1,2 @@ + +arm: wrong syndrome reported for FP and SIMD traps to AArch32 Hyp diff --git a/results/classifier/gemma3:12b/hypervisor/1156 b/results/classifier/gemma3:12b/hypervisor/1156 new file mode 100644 index 00000000..4da98ecd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1156 @@ -0,0 +1,2 @@ + +Incorrect implementation of vmsumudm instruction diff --git a/results/classifier/gemma3:12b/hypervisor/1167 b/results/classifier/gemma3:12b/hypervisor/1167 new file mode 100644 index 00000000..1fdc389d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1167 @@ -0,0 +1,2 @@ + +Does qemu-system-aarch64 support hyper-v elightenment feature for windows for arm guest? diff --git a/results/classifier/gemma3:12b/hypervisor/1182 b/results/classifier/gemma3:12b/hypervisor/1182 new file mode 100644 index 00000000..c0d4def9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1182 @@ -0,0 +1,70 @@ + +Hotplug device(device_add) immediately after starting a virtual machine triggers deadlock. +Description of problem: +Sometimes, hotplug device(device_add) immediately after starting a virtual machine triggers deadlock. + +Related commits: [7bed8995](https://gitlab.com/qemu-project/qemu/-/commit/7bed89958bfbf40df9ca681cefbdca63abdde39d) +Steps to reproduce: +1. start a virtual machine + +2. hotplug some device immediately(24 virtio-blk device etc.) + +3. repert step 1 and step 2 for several times, as I tried, deadlock will happen within 100 times. +Additional information: +I found similar problem [Issues 650](https://gitlab.com/qemu-project/qemu/-/issues/650)，but problem seems different. + +When qemu_main_loop deal with qmp_device_add command which will add a bottom half structure to qemu_aio_context's bh_list. + +At the same time, UEFI loader writing something to pflash device, address_space_write function get rcu_read_lock and poll aio request. + +Then, it will get the bottom half structure added by qemu_main_loop and go to qmp_device_add function. qmp_device_add function call drain_call_rcu function which will wait for all readers exit. Then it caused a deadlock. + + + +dead lock thread stack + +``` +#0 0x0000ffffb11e8ee4 in syscall () from target:/usr/lib64/libc.so.6 +#1 0x0000aaaadab2ce80 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /Images/jdx/code/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=ev@entry=0xffff87bfd890) at ../util/qemu-thread-posix.c:429 +#3 0x0000aaaadab35ed0 in drain_call_rcu () at ../util/rcu.c:347 +#4 0x0000aaaada55fa94 in qmp_device_add (qdict=<optimized out>, ret_data=<optimized out>, errp=<optimized out>) at ../softmmu/qdev-monitor.c:866 +#5 0x0000aaaadab1f01c in do_qmp_dispatch_bh (opaque=0xffffaf987ec8) at ../qapi/qmp-dispatch.c:128 +#6 0x0000aaaadab3d1b4 in aio_bh_call (bh=0xffff382d8190) at ../util/async.c:150 +#7 aio_bh_poll (ctx=ctx@entry=0xaaaaf8836ac0) at ../util/async.c:178 +#8 0x0000aaaadab29010 in aio_poll (ctx=ctx@entry=0xaaaaf8836ac0, blocking=blocking@entry=true) at ../util/aio-posix.c:712 +#9 0x0000aaaadaa060e8 in bdrv_poll_co (s=0xffff87bfda58) at /Images/jdx/code/qemu/block/block-gen.h:44 +#10 0x0000aaaadaa07134 in blk_pwrite (blk=0xaaaaf8b82400, offset=offset@entry=197120, bytes=bytes@entry=512, buf=0xffff87c30200, flags=flags@entry=0) at block/block-gen.c:685 +#11 0x0000aaaada35c330 in pflash_update (pfl=pfl@entry=0xaaaaf8b474f0, offset=197120, offset@entry=197124, size=size@entry=4) at ../hw/block/pflash_cfi01.c:395 +#12 0x0000aaaada35e1f8 in pflash_write (be=0, width=4, value=299045890, offset=197124, pfl=0xaaaaf8b474f0) at ../hw/block/pflash_cfi01.c:523 +#13 pflash_mem_write_with_attrs (opaque=0xaaaaf8b474f0, addr=197124, value=299045890, len=4, attrs=...) at ../hw/block/pflash_cfi01.c:682 +#14 0x0000aaaada918cbc in access_with_adjusted_size (addr=addr@entry=197124, value=value@entry=0xffff87bfdbf8, size=4, access_size_min=<optimized out>, access_size_max=<optimized out>, + access_fn=access_fn@entry=0xaaaada91b260 <memory_region_write_with_attrs_accessor>, mr=0xaaaaf8b478b0, attrs=...) at ../softmmu/memory.c:554 +#15 0x0000aaaada91cfc4 in memory_region_dispatch_write (mr=mr@entry=0xaaaaf8b478b0, addr=197124, data=<optimized out>, op=MO_32, attrs=attrs@entry=...) at ../softmmu/memory.c:1520 +#16 0x0000aaaada9245ec in flatview_write_continue (fv=fv@entry=0xffff38492110, addr=addr@entry=67305988, attrs=attrs@entry=..., ptr=ptr@entry=0xffffb1e13028, len=len@entry=4, addr1=<optimized out>, l=<optimized out>, + mr=0xaaaaf8b478b0) at /Images/jdx/code/qemu/include/qemu/host-utils.h:166 +#17 0x0000aaaada924844 in flatview_write (fv=0xffff38492110, addr=addr@entry=67305988, attrs=attrs@entry=..., buf=buf@entry=0xffffb1e13028, len=len@entry=4) at ../softmmu/physmem.c:2867 +#18 0x0000aaaada92825c in address_space_write (len=4, buf=0xffffb1e13028, attrs=..., addr=67305988, as=0xaaaadb4a4670 <address_space_memory>) at ../softmmu/physmem.c:2963 +#19 address_space_rw (as=0xaaaadb4a4670 <address_space_memory>, addr=67305988, attrs=attrs@entry=..., buf=buf@entry=0xffffb1e13028, len=4, is_write=<optimized out>) at ../softmmu/physmem.c:2973 +#20 0x0000aaaada9c7754 in kvm_cpu_exec (cpu=cpu@entry=0xaaaaf8c80530) at ../accel/kvm/kvm-all.c:2954 +#21 0x0000aaaada9c8adc in kvm_vcpu_thread_fn (arg=arg@entry=0xaaaaf8c80530) at ../accel/kvm/kvm-accel-ops.c:49 +#22 0x0000aaaadab2ba98 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504 +#23 0x0000ffffb118718c in ?? () from target:/usr/lib64/libc.so.6 +#24 0x0000ffffb11ed15c in ?? () from target:/usr/lib64/libc.so.6 + +``` + +call_rcu_thread stack +``` +Thread 2 (Thread 0xffffb0196900 (LWP 1018210) "qemu-system-aar"): +#0 0x0000ffffb11e8ee4 in syscall () from target:/usr/lib64/libc.so.6 +#1 0x0000aaaadab2ce80 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /Images/jdx/code/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=ev@entry=0xaaaadb4c3bb8 <rcu_gp_event>) at ../util/qemu-thread-posix.c:429 +#3 0x0000aaaadab35ce8 in wait_for_readers () at ../util/rcu.c:138 +#4 synchronize_rcu () at ../util/rcu.c:174 +#5 0x0000aaaadab36160 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:268 +#6 0x0000aaaadab2ba98 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504 +#7 0x0000ffffb118718c in ?? () from target:/usr/lib64/libc.so.6 +#8 0x0000ffffb11ed15c in ?? () from target:/usr/lib64/libc.so.6 + +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1182490 b/results/classifier/gemma3:12b/hypervisor/1182490 new file mode 100644 index 00000000..cab3da2b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1182490 @@ -0,0 +1,77 @@ + +[qemu-1.5] coroutine-win32.c broken on NULL pointer + +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 4340.0x163c] +qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, from_=0x3ba1c80) + at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47 +(gdb) bt +#0 qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, + from_=0x3ba1c80) at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47 +#1 coroutine_trampoline (co_=0x3ba1c80) + at /home/cauchy/vcs/git/qemu/coroutine-win32.c:58 +#2 0x0000000077098fed in ?? () +#3 0x0000000000000000 in ?? () +(gdb) +(gdb) info registers +rax 0x0 0 +rbx 0x3ba1c80 62528640 +rcx 0x0 0 +rdx 0x0 0 +rsi 0x770b28d0 1997220048 +rdi 0x3ba1b38 62528312 +rbp 0x0 0x0 +rsp 0xc0bff60 0xc0bff60 +r8 0x3184c0 3245248 +r9 0x43e31a 4449050 +r10 0x0 0 +r11 0x206 518 +r12 0x0 0 +r13 0x0 0 +r14 0x0 0 +r15 0x0 0 +rip 0x43e2cd 0x43e2cd <coroutine_trampoline+61> +eflags 0x10206 [ PF IF RF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 +(gdb) disassemble +Dump of assembler code for function coroutine_trampoline: + 0x000000000043e290 <+0>: push %rdi + 0x000000000043e291 <+1>: push %rsi + 0x000000000043e292 <+2>: push %rbx + 0x000000000043e293 <+3>: sub $0x30,%rsp + 0x000000000043e297 <+7>: mov %rcx,%rbx + 0x000000000043e29a <+10>: lea 0x26dc1f(%rip),%rcx # +0x6abec0 <__emutls_v.current> + 0x000000000043e2a1 <+17>: mov 0x6868dd68(%rip),%rax # 0x68acc010 + 0x000000000043e2a8 <+24>: mov %rax,0x28(%rsp) + 0x000000000043e2ad <+29>: xor %eax,%eax + 0x000000000043e2af <+31>: callq 0x695808 <__emutls_get_address> + 0x000000000043e2b4 <+36>: mov 0x9090d9(%rip),%rsi # +0xd47394 <__imp_SwitchToFiber> + 0x000000000043e2bb <+43>: mov %rax,%rdi + 0x000000000043e2be <+46>: xchg %ax,%ax + 0x000000000043e2c0 <+48>: mov 0x8(%rbx),%rcx + 0x000000000043e2c4 <+52>: callq *(%rbx) + 0x000000000043e2c6 <+54>: mov 0x10(%rbx),%rdx + 0x000000000043e2ca <+58>: mov %rdx,(%rdi) +=> 0x000000000043e2cd <+61>: movl $0x2,0x38(%rdx) + 0x000000000043e2d4 <+68>: mov 0x30(%rdx),%rcx + 0x000000000043e2d8 <+72>: callq *%rsi + 0x000000000043e2da <+74>: jmp 0x43e2c0 <coroutine_trampoline+48> +End of assembler dump. +(gdb) + + +From: + +qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, from_=0x3ba1c80) + at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47 + +We can see qemu_coroutine_switch was call with to_=NULL, then crashed at line 47: + +to->action = action; \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1184089 b/results/classifier/gemma3:12b/hypervisor/1184089 new file mode 100644 index 00000000..3c588665 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1184089 @@ -0,0 +1,13 @@ + +[Feature request] loadvm snapshot as read-only + +There are many ways to take and manage snapshots in QEMU, but one main feature that's missing is the ability to 'loadvm' a LIVE snapshot and have all future changes redirected to a temporary file. This would effectively be combining the -loadvm and -snapshot switches and make the snapshot read-only. With this feature, users would be provided a "sandbox" and be able to start and restart the same live snapshot without corrupting the image in doing so. + +I found a lot of discussion about this topic on the mailing list years ago, including some patch submissions, but none of the conversations panned out. + +http://lists.gnu.org/archive/html/qemu-discuss/2011-10/msg00011.html +http://copilotco.com/mail-archives/qemu.2008/msg00072.html +http://web.archiveorange.com/archive/v/1XS1vcusGInZKG2e0ImX +http://marc.info/?l=qemu-devel&m=117191084713590 + +What would it take for this feature to be added, and can we use the patches submitted by Eddie Kohler to enable this feature? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1193 b/results/classifier/gemma3:12b/hypervisor/1193 new file mode 100644 index 00000000..f560436b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1193 @@ -0,0 +1,17 @@ + +io_uring / iothread regression 7.1.0 +Description of problem: +After upgrading to 7.1.0, some of my libvirt VM's failed to boot. I have narrowed down the issue to the combination of: + +- io_uring +- iothread +Steps to reproduce: +1. set up a VM with iothread and io_uring +2. try to boot and watch it "hang" +Additional information: +Here's the relevant command line from the libvirt log: +``` +-blockdev '{"driver":"file","filename":"/mnt/data/VMs/Arch-Linux-x86_64-basic.qcow2","aio":"io_uring","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"virtio-blk-pci","iothread":"iothread1","bus":"pci.4","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk0","bootindex":1 }' \ +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1195 b/results/classifier/gemma3:12b/hypervisor/1195 new file mode 100644 index 00000000..3f8dc50c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1195 @@ -0,0 +1,19 @@ + +Race condition during QEMU exit cleanup can lead to deadlock +Description of problem: +During the cleanup phase of QEMU exiting, there is a small race condition window that can lead QEMU to lock up completely: +In the main QEMU thread, during the exit, the thread will execute the 'qemu_cleanup' function, which calls 'do_vm_stop', which calls 'pause_all_vcpus'. This method tries to (as the name suggests) stop/pause all the vcpu threads. At the same time, the vcpu thread might have just existed it's main mttcg exec loop, which means it will enter 'qemu_wait_io_event'. At this point, the following race condition can occur: +- vcpu_thread - cpus.c:416 <= enters qemu_wait_io_event +- shutdown_thread - cpus.c:555 <= enters pause_all_vcpus +- vcpu_thread - cpus.c:418 <= cpu_thread_is_idle returns true, cpu->stop not set yet +- shutdown_thread - cpus.c:560/561 <= sets cpu->stop and kicks the vcpu, but it's not waiting on cpu->halt_cond yet, so nothing happens +- vcpu_thread - cpus.c:423 <= starts waiting on cpu->halt_cond +- shutdown_thread - cpus.c:570 <= not all vcpus paused, so enters while loop +- shutdown_thread - cpus.c:571 <= starts waiting on qemu_pause_cond +- **deadlock** + +In my case, my plugin registers qemu_plugin_vcpu_idle_cb, so the race window is extended significantly in the vcpu thread (cpus.c:421) but I believe it can happen with the smaller race window as well. + +Note that this explanation is just based on my understanding of the code, and the final state of QEMU during the deadlock after I attached: The main thread (thread 1) was waiting on qemu_pause_cond in pause_all_vcpus, and the vcpu was waiting on cpu->halt_cond in qemu_wait_io_event, with no one else to wake either of them up. (This was following an exit that was triggered by a timeout signal) +Steps to reproduce: +This is a race condition, so I don't have a reliable reproducer. diff --git a/results/classifier/gemma3:12b/hypervisor/1197 b/results/classifier/gemma3:12b/hypervisor/1197 new file mode 100644 index 00000000..9eddba06 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1197 @@ -0,0 +1,816 @@ + +Use libvirt to create a Windows virtual machine and load NVIDIA's GPU. Installing NVIDIA driver causes the physical machine to restart +Description of problem: +As described in the title, When I created a Windows virtual machine and used NVIDIA's GPU and installed NVIDIA's driver in Windows VM, however, the physical machine will be restart. In the same create time, if it is a linux VM, It's ok! I don't know if there is a problem with my creation process or if the windows virtual machine is incompatible with NVIDIA graphics card. + + +GPU INFO: +``` +81:00.0 VGA compatible controller: NVIDIA Corporation GP106GL [Quadro P2000] (rev a1) +81:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller (rev a1) +``` + + +BR！ +Steps to reproduce: +1. +2. +3. +Additional information: +qemu info: +``` +libvirt-daemon-driver-qemu-4.5.0-36.el7_9.5.x86_64 +ipxe-roms-qemu-20180825-3.git133f4c.el7.noarch +qemu-kvm-common-1.5.3-175.el7_9.6.x86_64 +qemu-kvm-1.5.3-175.el7_9.6.x86_64 +qemu-img-1.5.3-175.el7_9.6.x86_64 +``` + + + +``` +<domain type="kvm"> + <name>win</name> + <uuid>a5efd8ed-fa6f-693c-2202-93183ec18b5e</uuid> + <description>None</description> + <memory unit="KiB">5242880</memory> + <currentMemory unit="KiB">5242880</currentMemory> + <vcpu placement="static">4</vcpu> + <os> + <type arch="x86_64" machine="pc-i440fx-rhel7.0.0">hvm</type> + <boot dev="hd"/> + <boot dev="cdrom"/> + <bootmenu enable="yes"/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode="host-passthrough" check="none"/> + <clock offset="utc"/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type="file" device="disk"> + <driver name="qemu" type="qcow2"/> + <source file="/opt/panafs/1374467833802939042/win.img"/> + <target dev="sda" bus="sata"/> + <address type="drive" controller="0" bus="0" target="0" unit="0"/> + </disk> + <disk type="file" device="cdrom"> + <driver name="qemu" type="raw"/> + <source file="/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso"/> + <target dev="hda" bus="ide"/> + <readonly/> + <address type="drive" controller="0" bus="1" target="0" unit="1"/> + </disk> + <disk type="file" device="cdrom"> + <driver name="qemu" type="raw"/> + <source file="/var/lib/libvirt/images/virtio-win-0.1.217.iso"/> + <target dev="hdb" bus="ide"/> + <readonly/> + <address type="drive" controller="0" bus="0" target="0" unit="1"/> + </disk> + <controller type="usb" index="0" model="piix3-uhci"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x2"/> + </controller> + <controller type="pci" index="0" model="pci-root"/> + <controller type="ide" index="0"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x1"/> + </controller> + <controller type="sata" index="0"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x04" function="0x0"/> + </controller> + <controller type="virtio-serial" index="0"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x0"/> + </controller> + <interface type="network"> + <mac address="52:54:00:1d:d8:7d"/> + <source network="default"/> + <model type="virtio"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/> + </interface> + <interface type="network"> + <mac address="52:54:00:09:bc:30"/> + <source network="default"/> + <model type="e1000"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x09" function="0x0"/> + </interface> + <serial type="pty"> + <target type="isa-serial" port="0"> + <model name="isa-serial"/> + </target> + </serial> + <console type="pty"> + <target type="serial" port="0"/> + </console> + <channel type="unix"> + <target type="virtio" name="org.qemu.guest_agent.0"/> + <address type="virtio-serial" controller="0" bus="0" port="2"/> + </channel> + <input type="mouse" bus="ps2"/> + <input type="tablet" bus="usb"> + <address type="usb" bus="0" port="1"/> + </input> + <input type="keyboard" bus="ps2"/> + <graphics type="vnc" port="-1" autoport="yes"> + <listen type="address"/> + </graphics> + <video> + <model type="cirrus" vram="16384" heads="1" primary="yes"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/> + </video> + <hostdev mode="subsystem" type="pci" managed="yes"> + <source> + <address domain="0x0000" bus="0x81" slot="0x00" function="0x0"/> + </source> + <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> + </hostdev> + <hostdev mode="subsystem" type="pci" managed="yes"> + <source> + <address domain="0x0000" bus="0x81" slot="0x00" function="0x1"/> + </source> + <address type="pci" domain="0x0000" bus="0x00" slot="0x08" function="0x0"/> + </hostdev> + <memballoon model="virtio"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x06" function="0x0"/> + </memballoon> + </devices> +</domain> +``` + + + +part log of VM: + +``` +2022-09-05 07:12:51.328+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid 49f538e1-4042-bbc4-1b2c-10f02219bba5 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:78:1a:32,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-3-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:12:51.328+0000: Domain id=3 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:14:02.309+0000: shutting down, reason=destroyed +2022-09-05 07:14:35.696+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid abcbac3c-fd61-57ac-f1ad-60387881c0a6 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-virtio-disk0 \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:94:04:a7,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-4-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:14:35.696+0000: Domain id=4 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:15:54.690+0000: shutting down, reason=destroyed +2022-09-05 07:16:18.098+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-5-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:16:18.098+0000: Domain id=5 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:33:42.873+0000: shutting down, reason=destroyed +2022-09-05 07:37:05.200+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-6-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:37:05.200+0000: Domain id=6 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:37:37.578+0000: shutting down, reason=destroyed +2022-09-05 07:37:44.799+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=33,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-7-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:37:44.799+0000: Domain id=7 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:49:11.497+0000: shutting down, reason=destroyed +2022-09-05 07:49:34.883+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-8-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=33,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-8-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:49:34.883+0000: Domain id=8 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +2022-09-05 08:08:31.206+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=29,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 08:08:31.206+0000: Domain id=1 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15043 +2022-09-06 02:39:26.089+0000: shutting down, reason=destroyed +2022-09-06 02:39:32.783+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on \ +-device ide-cd,bus=sata0.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=2 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 \ +-netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=33 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=34,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-7-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 02:39:32.783+0000: Domain id=7 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15043 +2022-09-06 02:40:52.065+0000: shutting down, reason=destroyed +2022-09-06 02:41:03.281+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-8-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=33 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=34,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-8-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 02:41:03.281+0000: Domain id=8 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +2022-09-06 03:08:33.510+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=29,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 03:08:33.510+0000: Domain id=1 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15135 +2022-09-06 03:09:18.992+0000: shutting down, reason=destroyed +2022-09-06 03:09:52.805+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=spice \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=29,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-2-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 03:09:52.805+0000: Domain id=2 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) + +(process:102539): Spice-WARNING **: 11:09:53.755: display-channel.c:2435:display_channel_validate_surface: canvas address is 0x55603dfbbb08 for 0 (and is NULL) + + +(process:102539): Spice-WARNING **: 11:09:53.755: display-channel.c:2436:display_channel_validate_surface: failed on 0 + +(process:102539): Spice-WARNING **: 11:09:53.755: red-worker.c:553:destroy_primary_surface: double destroy of primary surface + +(process:102539): Spice-WARNING **: 11:09:53.756: display-channel.c:2159:display_channel_create_surface: condition `!surface->context.canvas' failed +main_channel_link: add main channel client +main_channel_client_handle_pong: net test: latency 0.784000 ms, bitrate 50996015 bps (48.633590 Mbps) +red_qxl_set_cursor_peer: +inputs_connect: inputs channel client create +qemu: terminating on signal 15 from pid 15135 +2022-09-06 03:10:27.167+0000: shutting down, reason=destroyed +2022-09-06 03:10:39.556+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=29,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-3-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 127.0.0.1:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 03:10:39.556+0000: Domain id=3 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15135 +2022-09-06 03:50:33.032+0000: shutting down, reason=destroyed +2022-09-06 03:54:03.923+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=36 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=37,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-6-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 127.0.0.1:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 03:54:03.923+0000: Domain id=6 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +2022-09-06 04:16:48.831+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=30,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 127.0.0.1:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 04:16:48.831+0000: Domain id=1 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15130 +2022-09-06 07:52:07.759+0000: shutting down, reason=destroyed + + + + +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1199 b/results/classifier/gemma3:12b/hypervisor/1199 new file mode 100644 index 00000000..7d0f7204 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1199 @@ -0,0 +1,11 @@ + +Prevent virtual machine memory leakage +Description of problem: +The data written in the virtual machine does not clear the memory after the virtual machine is shut down. When the virtual machine with large memory is started, it may access the data of the previous virtual machine +Steps to reproduce: +1. create a virtual machine with large size memory( 80% of the host's Physical memory) +2. Request all free memory and write the characteristic string in vm +3. restart the vm +4. Request all free memory and query the last character string written +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1201446 b/results/classifier/gemma3:12b/hypervisor/1201446 new file mode 100644 index 00000000..b9a4391e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1201446 @@ -0,0 +1,27 @@ + +Instructions not supported by targeted CPU do not throw SIGILL + +We encountered a bug in another package that caused it to include CMOV instructions when targetting i486, resulting in an inability to run the package on real i486 and i586 hardware. We then attempted to use QEMU to reproduce the bug for easier debugging, since most developers have long since got rid of such old hardware. + +QEMU appears to continue to support *all* instructions when -cpu=486 is selected, regardless of what is advertised in CPUID to the guest. CPUID describes the host environment as a reasonably close approximation to a late-model i486, with very few instruction extensions - specifically excluding CMOV, which on real hardware is an optional extension to the i686 architecture. + +The result was that we could not reproduce the bug using QEMU, and must therefore attempt to debug it using a very limited stock of real hardware, which also has very limited performance for rebuilding the package. This completely defeats one of the main uses of QEMU, in our opinion. + +If this bug extends to other CPU architectures, it would affect all developers wishing to check whether their code conforms to restrictions imposed by any older or more restrictive ISA specification than the latest that QEMU supports, including the distinctions between ARMv7-A-NEON, ARMv7-A-VFPv3, ARMv7-A-VFPv3-d16, ARMv7-R, ARMv7-M, ARMv6-VFPv2, ARMv5-TE, ARMv4-T... all of which are currently shipping in new devices. + +Attached is a small C program which can easily be compiled to include CMOV instructions. It can be used to reproduce the bug: + +$ gcc -march=i486 -O2 -c minmax.c -o minmax +$ ./minmax +No arguments! +$ ./minmax 5 6 7 +max: 7 min: 5 +$ gcc -march=pentium2 -O2 -c minmax.c -o minmax-p2 +$ ./minmax-p2 +No arguments! +$ ./minmax-p2 5 6 7 +[Expected, occurs on real i4/586 hardware:] Illegal instruction +[Actual, within QEMU v1.2.0 with -cpu=486:] max: 7 min: 5 +$ + +The bug is likely not limited to CMOV, but would also apply to more recent ISA extensions - so 3DNow! instructions would appear to run on Intel guest CPUs, AVX on a Pentium-2, and other such weirdness. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1207 b/results/classifier/gemma3:12b/hypervisor/1207 new file mode 100644 index 00000000..86c1c238 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1207 @@ -0,0 +1,4 @@ + +Cannot use qcow2 to create a VM on apple silicon macbook +Description of problem: +Nothing to output when I input the command above. And it seems not to boot successfully. diff --git a/results/classifier/gemma3:12b/hypervisor/1211910 b/results/classifier/gemma3:12b/hypervisor/1211910 new file mode 100644 index 00000000..e7975086 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1211910 @@ -0,0 +1,9 @@ + +Logical to linear address translation is wrong for 32-bit guests on a 64-bit hypervisor + +I run a 64-bit hypervisor in qemu-system-x86_64 (without KVM) and on top of that I have a 32-bit guest. The guest configures the code-segment to have a base of 0x4000_0000 and a limit of 0xFFFF_FFFF with paging disabled. Thus, if a logical address of e.g. 0xC000_0000 is used, it should be translated to 0x0000_0000 (linear and physical), because of the overflow that happens. +But this does not happen with the described setup. Instead, qemu seems to calculate the logical to linear translation with 64-bit addresses so that no overflow happens. Consequently, the resulting address is 0x1_0000_0000 and this gets written to exitinfo2 in the VMCB structure. This causes trouble for hypervisors that expect the upper 32 bits of exitinfo2 to be 0 for 32-bit guests. + +Note also that the exact same setup runs fine on real AMD machines with SVM. That is, the upper 32 bits in exitinfo2 are always 0 because of the overflow. + +I've tested that with the latest development version of QEMU (commit 328465fd9f3a628ab320b5959d68d3d49df58fa6). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1214884 b/results/classifier/gemma3:12b/hypervisor/1214884 new file mode 100644 index 00000000..ccabf5e2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1214884 @@ -0,0 +1,10 @@ + +Support VDI (Virtualbox) snapshots + +Please support Snapshots in VDI images. + +It seems that VirtualBox uses a snapshot for any changes to the main system disc. Even when the user does not create a snapshot. + +So if I want to mount a VDI disc with the recent system changes, I have to mount the Snapshot. + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1215 b/results/classifier/gemma3:12b/hypervisor/1215 new file mode 100644 index 00000000..6c99b424 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1215 @@ -0,0 +1,73 @@ + +block-stream qmp command regression in 7.1.0 +Description of problem: +After `block-stream` qmp commands, guest was hanged when using `iothread` option. +According to b1e1af3, there are some change at drain blockdev subtree and strong reference to base node. +We couldn't produce this issue when we reverted the commit. +It seems to be raised by racing acquiring aio_lock between iothread and main thread. +Steps to reproduce: +1. Start Guest with upper command. +2. After started, operate `block-stream` command to qmp socket +``` +echo '{"execute":"qmp_capabilities"}{ + "execute":"block-stream", + "arguments":{ + "job-id":"hangTest", + "device":"vdaFile" + } +}' | sudo nc -U /var/run/monitor_a9b43742-9117-4aae-8887-24bdb017ec20 -N +``` +Additional information: +- gdb debug stack +``` +Thread 1 (Thread 0x7fcfaed84600 (LWP 162409) "qemu-system-x86"): +#0 0x00007fcfaf108e7e in __ppoll (fds=0x5634a9b6b240, nfds=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42 +#1 0x00005634a7be22dd in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:64 +#2 0x00005634a7bc02c9 in fdmon_poll_wait (ctx=0x5634a990eec0, ready_list=0x7ffcb2ce4fb8, timeout=-1) at ../util/fdmon-poll.c:80 +#3 0x00005634a7bbf9c9 in aio_poll (ctx=ctx@entry=0x5634a990eec0, blocking=blocking@entry=true) at ../util/aio-posix.c:660 +#4 0x00005634a7ac849d in bdrv_parent_drained_end_single (c=c@entry=0x5634a9b4bb30) at ../block/io.c:76 +#5 0x00005634a7a98240 in bdrv_replace_child_noperm (childp=0x5634a9b61240, new_bs=0x0, free_empty_child=<optimized out>) at ../block.c:2910 +#6 0x00005634a7a987fe in bdrv_replace_child_tran (childp=<optimized out>, new_bs=<optimized out>, tran=<optimized out>, free_empty_child=<optimized out>) at ../block.c:2444 +#7 0x00005634a7a988bc in bdrv_remove_file_or_backing_child (bs=bs@entry=0x5634a9b5d1f0, child=child@entry=0x5634a9b4bb30, tran=tran@entry=0x5634aa415fc0) at ../block.c:5155 +#8 0x00005634a7a9fac6 in bdrv_remove_file_or_backing_child (tran=0x5634aa415fc0, child=0x5634a9b4bb30, bs=0x5634a9b5d1f0) at ../block.c:5133 +#9 bdrv_set_file_or_backing_noperm (parent_bs=parent_bs@entry=0x5634a9b5d1f0, child_bs=child_bs@entry=0x0, is_backing=is_backing@entry=true, tran=tran@entry=0x5634aa415fc0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3412 +#10 0x00005634a7a9fd04 in bdrv_set_backing_noperm (errp=0x7ffcb2ce5150, tran=0x5634aa415fc0, backing_hd=0x0, bs=0x5634a9b5d1f0) at ../block.c:3449 +#11 bdrv_set_backing_hd (bs=bs@entry=0x5634a9b5d1f0, backing_hd=backing_hd@entry=0x0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3461 +#12 0x00005634a7b25e19 in stream_prepare (job=0x5634a9e83da0) at ../block/stream.c:85 +#13 0x00005634a7aa922e in job_prepare (job=0x5634a9e83da0) at ../job.c:837 +#14 job_txn_apply (fn=<optimized out>, job=0x5634a9e83da0) at ../job.c:158 +#15 job_do_finalize (job=0x5634a9e83da0) at ../job.c:854 +#16 0x00005634a7aa9726 in job_exit (opaque=0x5634a9e83da0) at ../job.c:941 +#17 0x00005634a7bd26b4 in aio_bh_call (bh=0x7fcfa0824010) at ../util/async.c:150 +#18 aio_bh_poll (ctx=ctx@entry=0x5634a990eec0) at ../util/async.c:178 +#19 0x00005634a7bbf602 in aio_dispatch (ctx=0x5634a990eec0) at ../util/aio-posix.c:421 +#20 0x00005634a7bd22f2 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:320 +#21 0x00007fcfaf3c0d1b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#22 0x00005634a7bde7c0 in glib_pollfds_poll () at ../util/main-loop.c:297 +#23 os_host_main_loop_wait (timeout=114194793) at ../util/main-loop.c:320 +#24 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:596 +#25 0x00005634a784fdc3 in qemu_main_loop () at ../softmmu/runstate.c:734 +#26 0x00005634a769f9e0 in qemu_main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:38 +--Type <RET> for more, q to quit, c to continue without paging-- +#27 0x00007fcfaf019d90 in __libc_start_call_main (main=main@entry=0x5634a769b0c0 <main>, argc=argc@entry=56, argv=argv@entry=0x7ffcb2ce54c8) at ../sysdeps/nptl/libc_start_call_main.h:58 +#28 0x00007fcfaf019e40 in __libc_start_main_impl (main=0x5634a769b0c0 <main>, argc=56, argv=0x7ffcb2ce54c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcb2ce54b8) at ../csu/libc-start.c:392 +#29 0x00005634a769f905 in _start () +``` +- iothread gdb stack +``` +Thread 3 (Thread 0x7fcfae47e640 (LWP 162411) "IO iothread1"): +#0 futex_wait (private=0, expected=2, futex_word=0x5634a9b49620) at ../sysdeps/nptl/futex-internal.h:146 +#1 __GI___lll_lock_wait (futex=futex@entry=0x5634a9b49620, private=0) at ./nptl/lowlevellock.c:49 +#2 0x00007fcfaf0880dd in lll_mutex_lock_optimized (mutex=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:48 +#3 ___pthread_mutex_lock (mutex=mutex@entry=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:128 +#4 0x00005634a7bc25b8 in qemu_mutex_lock_impl (mutex=0x5634a9b49620, file=0x5634a7da2997 "../util/async.c", line=682) at ../util/qemu-thread-posix.c:88 +#5 0x00005634a7bd24a5 in aio_context_acquire (ctx=0x5634a9b495c0) at ../util/async.c:682 +#6 co_schedule_bh_cb (opaque=0x5634a9b495c0) at ../util/async.c:520 +#7 0x00005634a7bd26b4 in aio_bh_call (bh=0x5634a9b494a0) at ../util/async.c:150 +#8 aio_bh_poll (ctx=ctx@entry=0x5634a9b495c0) at ../util/async.c:178 +#9 0x00005634a7bbf754 in aio_poll (ctx=0x5634a9b495c0, blocking=blocking@entry=true) at ../util/aio-posix.c:712 +#10 0x00005634a7a9392a in iothread_run (opaque=opaque@entry=0x5634a9998700) at ../iothread.c:67 +#11 0x00005634a7bc21d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504 +#12 0x00007fcfaf084b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#13 0x00007fcfaf116a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1217339 b/results/classifier/gemma3:12b/hypervisor/1217339 new file mode 100644 index 00000000..3b971f9d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1217339 @@ -0,0 +1,8 @@ + +SIGQUIT to send ACPI-shutdown to Guest + +When qemu receives SIGQUIT, it should first try to run system_powerdown (giving the guest an ACPI signal to begin the shutdown process), before ending the whole qemu process. + +At this point there is no way to do a graceful shutdown if you do not have access to the monitor and you do not use any wrapper like libvirt. + +If, for some reason SIGQUIT would not be accepted as the signal, take any free to use signal, like SIGUSR1. There should be a way to get ACPI shutdown sent to the guest. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1219207 b/results/classifier/gemma3:12b/hypervisor/1219207 new file mode 100644 index 00000000..1c89ec61 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1219207 @@ -0,0 +1,58 @@ + +QMP (32 bit only) segfaults in query-tpm-types when compiled with --enable-tpm + +NB: This bug ONLY happens on i686. When qemu is compiled for x86-64, the bug does NOT happen. + +$ ./configure --enable-tpm +$ make +$ (sleep 5; printf '{"execute":"qmp_capabilities"}\n{"execute":"query-tpm-types"}\n') | ./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 6, "major": 1}, "package": ""}, "capabilities": []}} +{"return": {}} +Segmentation fault (core dumped) + +The stack trace is: + +#0 output_type_enum (v=0xb9938228, obj=0x5, + strings=0xb77f0320 <TpmType_lookup>, kind=0xb767f1d4 "TpmType", name=0x0, + errp=0xbfec4628) at qapi/qapi-visit-core.c:306 +#1 0xb762b3b5 in visit_type_enum (v=v@entry=0xb9938228, obj=0x5, + strings=0xb77f0320 <TpmType_lookup>, kind=kind@entry=0xb767f1d4 "TpmType", + name=name@entry=0x0, errp=errp@entry=0xbfec4628) + at qapi/qapi-visit-core.c:114 +#2 0xb74a9ef4 in visit_type_TpmType (errp=0xbfec4628, name=0x0, + obj=<optimized out>, m=0xb9938228) at qapi-visit.c:5220 +#3 visit_type_TpmTypeList (m=0xb9938228, obj=obj@entry=0xbfec4678, + name=name@entry=0xb76545a6 "unused", errp=errp@entry=0xbfec4674) + at qapi-visit.c:5206 +#4 0xb74c403e in qmp_marshal_output_query_tpm_types (errp=0xbfec4674, + ret_out=0xbfec46d8, ret_in=0xb993f490) at qmp-marshal.c:3795 +#5 qmp_marshal_input_query_tpm_types (mon=0xb9937098, qdict=0xb99379a0, + ret=0xbfec46d8) at qmp-marshal.c:3817 +#6 0xb7581d7a in qmp_call_cmd (cmd=<optimized out>, params=0xb99379a0, + mon=0xb9937098) at /home/rjones/d/qemu/monitor.c:4644 +#7 handle_qmp_command (parser=0xb99370ec, tokens=0xb9941438) + at /home/rjones/d/qemu/monitor.c:4710 +#8 0xb7631d8f in json_message_process_token (lexer=0xb99370f0, + token=0xb993f3a8, type=JSON_OPERATOR, x=29, y=1) + at qobject/json-streamer.c:87 +#9 0xb764579b in json_lexer_feed_char (lexer=lexer@entry=0xb99370f0, + ch=<optimized out>, flush=flush@entry=false) at qobject/json-lexer.c:303 +#10 0xb76458c8 in json_lexer_feed (lexer=lexer@entry=0xb99370f0, + buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1) + at qobject/json-lexer.c:356 +#11 0xb7631fab in json_message_parser_feed (parser=0xb99370ec, + buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1) + at qobject/json-streamer.c:110 +#12 0xb75803eb in monitor_control_read (opaque=0xb9937098, + buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=1) at /home/rjones/d/qemu/monitor.c:4731 +#13 0xb74b191e in qemu_chr_be_write (len=<optimized out>, + buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", s=0xb9935800) at qemu-char.c:165 +#14 fd_chr_read (chan=0xb9935870, cond=(G_IO_IN | G_IO_HUP), opaque=0xb9935800) + at qemu-char.c:841 +#15 0xb71f6876 in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0 +#16 0xb71b0286 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#17 0xb747a13e in glib_pollfds_poll () at main-loop.c:189 +#18 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:234 +#19 main_loop_wait (nonblocking=1) at main-loop.c:484 +#20 0xb7309f11 in main_loop () at vl.c:2090 +#21 main (argc=8, argv=0xbfec5c14, envp=0xbfec5c38) at vl.c:4435 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1220 b/results/classifier/gemma3:12b/hypervisor/1220 new file mode 100644 index 00000000..0c7c9d8a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1220 @@ -0,0 +1,17 @@ + +when migrate,I unplugged the disk, why can't I force cancel the job task use qmp +Description of problem: +when migrate,I unplugged the disk,the block job will hung,but why can't I force cancel the job task +Steps to reproduce: +1.migrate a guset to another host with non-share disk (iscsi) + +2.unplug the disk + +3.then force cancel the block job task + + +but it not work,the cancle handle is not work + + + + diff --git a/results/classifier/gemma3:12b/hypervisor/1223 b/results/classifier/gemma3:12b/hypervisor/1223 new file mode 100644 index 00000000..ef611e74 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1223 @@ -0,0 +1,12 @@ + +When the disk is offline, why does the migration not time out and the virtual machine keeps hanging +Description of problem: +I want to the migrate end auto after the disk is offline +Steps to reproduce: +1.migrate to other host + +2.Manually construct disk offline when migrating + +3.the vm is hangs,and migrate wait for the disk recovery,i need to it timeout and report the failed migration +rather than hangs ,what should i do + diff --git a/results/classifier/gemma3:12b/hypervisor/1227 b/results/classifier/gemma3:12b/hypervisor/1227 new file mode 100644 index 00000000..8b68c9e9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1227 @@ -0,0 +1,2 @@ + +Guest Agent not waiting for Linux services to stop during shutdown diff --git a/results/classifier/gemma3:12b/hypervisor/1230 b/results/classifier/gemma3:12b/hypervisor/1230 new file mode 100644 index 00000000..13b41faf --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1230 @@ -0,0 +1,24 @@ + +qtest-aarch64/migration-test non-deterministic test failure +Description of problem: +The test suite fails: +``` +Summary of Failures: + + 32/619 qemu:qtest+qtest-aarch64 / qtest-aarch64/migration-test ERROR 161.19s killed by signal 6 SIGABRT + + +Ok: 552 +Expected Fail: 0 +Fail: 1 +Unexpected Pass: 0 +Skipped: 66 +Timeout: 0 + +Full log written to /tmp/guix-build-qemu-7.1.0.drv-0/qemu-7.1.0/b/qemu/meson-logs/testlog.txt +make: *** [Makefile.mtest:25: do-meson-check] Error 1 +``` + +See the full build log below. +Additional information: +[qt60pm4fcc63jcbwfgz86z6cwqgx4zgm-qemu-7.1.0.txt.gz](/uploads/6d7f0da152193213a7fe694e2d535879/qt60pm4fcc63jcbwfgz86z6cwqgx4zgm-qemu-7.1.0.txt.gz) diff --git a/results/classifier/gemma3:12b/hypervisor/1243968 b/results/classifier/gemma3:12b/hypervisor/1243968 new file mode 100644 index 00000000..9fb52d0a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1243968 @@ -0,0 +1,34 @@ + +VMware ESXi on QEmu Kernel Panic + +I attempted to install ESXi 5.5 (the free version) into a QEmu 1.6.1 VM. The guest OS does have the svm capabilities, but it appears VMware is trying to do some kind of hypercall that crashes the guest. + +There is more information here: https://communities.vmware.com/message/2297382 + +It seems to me that this stubbed feature should just be disabled if it is unusable. Or at the very least I should be able to disable it at run-time with a command-line argument. + +Is there some way to disable all the hypervisor features that makes it very obvious to a guest os that it is running inside a VM? It would be great if I could install a software and it would actually work (even if it's slow with those features disabled). + +FYI, my guest OS capabilities are: + +# cat /proc/cpuinfo +processor : 0 +vendor_id : AuthenticAMD +cpu family : 6 +model : 2 +model name : QEMU Virtual CPU version 1.5.3 +stepping : 3 +microcode : 0x1000065 +cpu MHz : 1999.999 +cache size : 512 KB +fpu : yes +fpu_exception : yes +cpuid level : 4 +wp : yes +flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm nopl pni cx16 popcnt hypervisor lahf_lm svm abm sse4a +bogomips : 3999.99 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/125 b/results/classifier/gemma3:12b/hypervisor/125 new file mode 100644 index 00000000..dd3f40ef --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/125 @@ -0,0 +1,2 @@ + +x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack diff --git a/results/classifier/gemma3:12b/hypervisor/1253465 b/results/classifier/gemma3:12b/hypervisor/1253465 new file mode 100644 index 00000000..626ce639 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1253465 @@ -0,0 +1,9 @@ + +qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 + +qemu-img convert in.vmdk -O RAW out.img + +Fails with: +qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 + +qemu-img version 1.6.1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1255 b/results/classifier/gemma3:12b/hypervisor/1255 new file mode 100644 index 00000000..da65f3b2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1255 @@ -0,0 +1,12 @@ + +32bit qemu-arm fails to run systemctl "Allocating guest commpage: Cannot allocate memory" +Description of problem: +I am using a bare minimal install of the latest 32 bit version of debian with only ssh installed. I have compiled qemu from the latest git with "./configure --target-list=arm-linux-user --static --disable-pie". When I try to run systemctl from the latest version of raspbian, I experience the error: "Allocating guest commpage: Cannot allocate memory". +Steps to reproduce: +1. Download and extract the included systemctl and required libs. [systemctl+libs.tgz](/uploads/a2834ed651a981fded4bcc19ea9ca31b/systemctl+libs.tgz) +2. run "qemu-arm -L ./ systemctl --version" +Additional information: +- I think this is related to [Issue 690](https://gitlab.com/qemu-project/qemu/-/issues/690). +- When I run "qemu-arm -L ./ -B 0x20000 systemctl --version" there is no error. +- The error still happens when setting vm.mmap_min_addr to 0. +- The error does not occur on v5.0.0, but does occur on v5.1.0 and v6.1.0. diff --git a/results/classifier/gemma3:12b/hypervisor/1257 b/results/classifier/gemma3:12b/hypervisor/1257 new file mode 100644 index 00000000..07147ee6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1257 @@ -0,0 +1,4 @@ + +Windows guest agent shutdown requires user response to complete +Additional information: +The shutdown operation triggered by the Windows Guest Agent should prevent the system from waiting for a user response concerning unsaved work of open desktop applications. Instead, applications and services should be closed as gracefully as possible automatically, in advance of the power down event on the emulated hardware. diff --git a/results/classifier/gemma3:12b/hypervisor/1261320 b/results/classifier/gemma3:12b/hypervisor/1261320 new file mode 100644 index 00000000..2e799353 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1261320 @@ -0,0 +1,16 @@ + +Virtual Disk with over 16TB + +Hi, + +is there a option to create a disk for a vm with a size over 16TB. + +the problem that after the diskfile reach 16TB, the disk get a state of read-only at this limit. +I know, that 16TB file size is max, is there a option to create the disk in mutliple files? +we want to use 22 TB. in the VM + +To attach a partition directly to the vm, is not what we want to do. + +best regards + +Chris \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1270 b/results/classifier/gemma3:12b/hypervisor/1270 new file mode 100644 index 00000000..b995a288 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1270 @@ -0,0 +1,15 @@ + +Guest freezes if memory backing using memfd/shared/ +Description of problem: +Guest VM freezes with the following memory backing is set. Required to for virtiofs, but just setting the following the guest will freeze in around 2hours, no logs or errors generate. + + <memoryBacking> + <source type='memfd'/> + <access mode='shared'/> + </memoryBacking> +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1272 b/results/classifier/gemma3:12b/hypervisor/1272 new file mode 100644 index 00000000..f4d93608 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1272 @@ -0,0 +1,51 @@ + +qemu 7.1: assertion faillure with virtio-scsi in `blk_set_enable_write_cache` +Description of problem: +During the guest boot qemu crashes with the following error: + +> qemu-system-x86_64: ../src/block/block-backend.c:1949: blk_set_enable_write_cache: Assertion `qemu_in_main_thread()' failed. +Steps to reproduce: +1. Start a windows guest +Additional information: +Stacktrace: + +``` +#0 0x00007fd6c3515ce1 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007fd6c34ff537 in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x00007fd6c34ff40f in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#3 0x00007fd6c350e662 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 +#4 0x000056149e2cea03 in blk_set_enable_write_cache (wce=true, blk=0x5614a01c27f0) at ../src/block/block-backend.c:1949 +#5 0x000056149e2d0a67 in blk_set_enable_write_cache (blk=0x5614a01c27f0, wce=<optimized out>) at ../src/block/block-backend.c:1951 +#6 0x000056149dfe9c59 in scsi_disk_apply_mode_select (p=0x7fd6b400c00e "\004", page=<optimized out>, s=<optimized out>) at ../src/hw/scsi/scsi-disk.c:1520 +#7 mode_select_pages (change=true, len=18, p=0x7fd6b400c00e "\004", r=0x7fd6b4001ff0) at ../src/hw/scsi/scsi-disk.c:1570 +#8 scsi_disk_emulate_mode_select (inbuf=<optimized out>, r=0x7fd6b4001ff0) at ../src/hw/scsi/scsi-disk.c:1640 +#9 scsi_disk_emulate_write_data (req=0x7fd6b4001ff0) at ../src/hw/scsi/scsi-disk.c:1934 +#10 0x000056149e18ff16 in virtio_scsi_handle_cmd_req_submit (req=<optimized out>, req=<optimized out>, s=0x5614a12f16b0) at ../src/hw/scsi/virtio-scsi.c:719 +#11 virtio_scsi_handle_cmd_vq (vq=0x7fd6bab92140, s=0x5614a12f16b0) at ../src/hw/scsi/virtio-scsi.c:761 +#12 virtio_scsi_handle_cmd (vq=<optimized out>, vdev=<optimized out>) at ../src/hw/scsi/virtio-scsi.c:775 +#13 virtio_scsi_handle_cmd (vdev=0x5614a12f16b0, vq=0x7fd6bab92140) at ../src/hw/scsi/virtio-scsi.c:765 +#14 0x000056149e1a8aa6 in virtio_queue_notify_vq (vq=0x7fd6bab92140) at ../src/hw/virtio/virtio.c:2365 +#15 0x000056149e3ccea5 in aio_dispatch_handler (ctx=ctx@entry=0x5614a01babe0, node=<optimized out>) at ../src/util/aio-posix.c:369 +#16 0x000056149e3cd868 in aio_dispatch_ready_handlers (ready_list=0x7fd6c09b2680, ctx=0x5614a01babe0) at ../src/util/aio-posix.c:399 +#17 aio_poll (ctx=0x5614a01babe0, blocking=blocking@entry=true) at ../src/util/aio-posix.c:713 +#18 0x000056149e2a7796 in iothread_run (opaque=opaque@entry=0x56149ffde500) at ../src/iothread.c:67 +#19 0x000056149e3d0859 in qemu_thread_start (args=0x7fd6c09b26f0) at ../src/util/qemu-thread-posix.c:504 +#20 0x00007fd6c36b9ea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#21 0x00007fd6c35d9aef in clone () from /lib/x86_64-linux-gnu/libc.so.6 +``` + +The crash was bisected to: + +``` +commit b1c073490553f80594b903ceedfc7c1aef6b1b19 +Author: Hanna Reitz <hreitz@redhat.com> +Date: Tue Mar 29 11:35:45 2022 +0200 + + main-loop: Disable GLOBAL_STATE_CODE() assertions +``` + +I have not been able to reproduce the bug with a linux guest nor with a fresh windows installation. + +The crashes appears with either `writethrough` and `directsync` cache modes but not with `writeback` `none` and `unsafe`. + +Note: if needed I can extract (privately) provide a disk image demonstrating the behavior diff --git a/results/classifier/gemma3:12b/hypervisor/1283 b/results/classifier/gemma3:12b/hypervisor/1283 new file mode 100644 index 00000000..8cac802a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1283 @@ -0,0 +1,83 @@ + +Live migration cause scsi_req_unref: Assertion `req->refcount > 0' failed +Description of problem: +During live migration, copy file from one folder to another. Migration can succeed. After a while, copy can't finish and in target host qemu crash: +``` +qemu-system-x86_64: ../hw/scsi/scsi-bus.c:1366: scsi_req_unref: Assertion `req->refcount > 0' failed. +2022-10-28 03:22:54.948+0000: shutting down, reason=crashed +``` +libvirt configure related: +``` + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/images/gen-l-vrt-295-008/swx-jd01-001-new.img'/> + <target dev='sda' bus='scsi'/> + <alias name='ua-box-volume-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='scsi' index='0' model='lsilogic'> + <address type='pci' domain='0x0000' bus='0x03' slot='0x01' function='0x0'/> + </controller> +``` +If change `bus='scsi'` to `bus='sata'`, same test steps can pass. +Steps to reproduce: +1. Inside VM +``` +fallocate -l 10G /tmp/test.img +cp /tmp/test.img / +``` +2. Same time, migrate VM to another server +``` +virsh migrate --verbose --live --persistent swx-jd01-001 qemu+ssh://gen-l-vrt-294/system --unsafe --auto-converge --auto-converge-initial 60 --auto-converge-increment 20 + +``` +3. After a while, cp can't finish and qemu crash on destination server with assert fail. +Additional information: +stack traces: +``` +#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140544841483840) at ./nptl/pthread_kill.c:44 +#1 __pthread_kill_internal (signo=6, threadid=140544841483840) at ./nptl/pthread_kill.c:78 +#2 __GI___pthread_kill (threadid=140544841483840, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 +#3 0x00007fd3284f9476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#4 0x00007fd3284df7f3 in __GI_abort () at ./stdlib/abort.c:79 +#5 0x00007fd3284df71b in __assert_fail_base + (fmt=0x7fd328694150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55791c97acbb "req->refcount > 0", file=0x55791c97ac7f "../hw/scsi/scsi-bus.c", line=1366, function=<optimized out>) + at ./assert/assert.c:92 +#6 0x00007fd3284f0e96 in __GI___assert_fail + (assertion=assertion@entry=0x55791c97acbb "req->refcount > 0", file=file@entry=0x55791c97ac7f "../hw/scsi/scsi-bus.c", line=line@entry=1366, function=function@entry=0x55791c97b2a0 <__PRETTY_FUNCTION__.14> "scsi_req_unref") at ./assert/assert.c:101 +#7 0x000055791c499a2e in scsi_req_unref (req=<optimized out>) at ../hw/scsi/scsi-bus.c:1366 +#8 0x000055791c49b61f in scsi_device_purge_requests (sdev=sdev@entry=0x55791e6e0c00, sense=...) at ../hw/scsi/scsi-bus.c:1639 +#9 0x000055791c49d704 in scsi_disk_reset (dev=0x55791e6e0c00) at ../hw/scsi/scsi-disk.c:2336 +#10 0x000055791c72a6ed in qdev_reset_one (dev=<optimized out>, opaque=<optimized out>) at ../hw/core/qdev.c:254 +#11 0x000055791c726fa9 in qbus_walk_children + (bus=<optimized out>, pre_devfn=0x55791c728770 <qdev_prereset>, pre_busfn=0x55791c7286a0 <qbus_prereset>, post_devfn=0x55791c72a6e0 <qdev_reset_one>, post_busfn=0x55791c728ae0 <qbus_reset_one>, opaque=0x0) at ../hw/core/bus.c:54 +#12 0x000055791c72a790 in qdev_walk_children + (opaque=0x0, post_busfn=0x55791c728ae0 <qbus_reset_one>, post_devfn=0x55791c72a6e0 <qdev_reset_one>, pre_busfn=0x55791c7286a0 <qbus_prereset>, pre_devfn=0x55791c728770 <qdev_prereset>, dev=0x55791ed2a430) at ../hw/core/qdev.c:413 +#13 qdev_reset_all (dev=0x55791ed2a430) at ../hw/core/qdev.c:272 +#14 0x000055791c688134 in memory_region_write_accessor (mr=mr@entry=0x55791ed2ae60, addr=20, value=value@entry=0x7fd32559f618, size=size@entry=1, shift=<optimized out>, mask=mask@entry=255, attrs=...) + at ../softmmu/memory.c:492 +#15 0x000055791c6858c6 in access_with_adjusted_size + (addr=addr@entry=20, value=value@entry=0x7fd32559f618, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55791c6880b0 <memory_region_write_accessor>, mr=0x55791ed2ae60, attrs=...) at ../softmmu/memory.c:554 +#16 0x000055791c689bf2 in memory_region_dispatch_write (mr=mr@entry=0x55791ed2ae60, addr=20, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../softmmu/memory.c:1521 +#17 0x000055791c690cf0 in flatview_write_continue (fv=fv@entry=0x55791e729ac0, addr=addr@entry=4257226772, attrs=..., + attrs@entry=..., ptr=ptr@entry=0x7fd328d36028, len=len@entry=1, addr1=<optimized out>, l=<optimized out>, mr=0x55791ed2ae60) at /opt/qemu/include/qemu/host-utils.h:166 +#18 0x000055791c690fb0 in flatview_write (fv=0x55791e729ac0, addr=addr@entry=4257226772, attrs=attrs@entry=..., buf=buf@entry=0x7fd328d36028, len=len@entry=1) at ../softmmu/physmem.c:2867 +#19 0x000055791c694799 in address_space_write (len=1, buf=0x7fd328d36028, attrs=..., addr=4257226772, as=0x55791d08a740 <address_space_memory>) at ../softmmu/physmem.c:2963 +#20 address_space_rw (as=0x55791d08a740 <address_space_memory>, addr=4257226772, attrs=attrs@entry=..., buf=buf@entry=0x7fd328d36028, len=1, is_write=<optimized out>) at ../softmmu/physmem.c:2973 +#21 0x000055791c71d19e in kvm_cpu_exec (cpu=cpu@entry=0x55791dc9d890) at ../accel/kvm/kvm-all.c:2954 +#22 0x000055791c71e6c5 in kvm_vcpu_thread_fn (arg=arg@entry=0x55791dc9d890) at ../accel/kvm/kvm-accel-ops.c:49 +#23 0x000055791c885be1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504 +#24 0x00007fd32854bb43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#25 0x00007fd3285dcbb4 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100 +``` +Guest disk partition +``` +root@swx-jd01-001:~# lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 64G 0 disk +├─sda1 8:1 0 512M 0 part /boot/efi +├─sda2 8:2 0 1K 0 part +└─sda5 8:5 0 63.5G 0 part + ├─vgwin--dbausdhrjgi-root 253:0 0 62.6G 0 lvm / + └─vgwin--dbausdhrjgi-swap_1 253:1 0 980M 0 lvm [SWAP] +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1297 b/results/classifier/gemma3:12b/hypervisor/1297 new file mode 100644 index 00000000..265b35ee --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1297 @@ -0,0 +1,2 @@ + +qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) diff --git a/results/classifier/gemma3:12b/hypervisor/1304 b/results/classifier/gemma3:12b/hypervisor/1304 new file mode 100644 index 00000000..2b7fbbfa --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1304 @@ -0,0 +1,10 @@ + +loadvm for arm vexpress-a9 +Description of problem: + +Steps to reproduce: +1. savevm test +2. loadvm test +3. After I execute savevm and loadvm,the guest is not responding +Additional information: +I have read this issue(https://github.com/panda-re/panda/issues/643). If secure is set to off,the guest works well. But I need to use security extensions,so secure cannot be set to off.What do I need to do to solve this problem？ diff --git a/results/classifier/gemma3:12b/hypervisor/1305400 b/results/classifier/gemma3:12b/hypervisor/1305400 new file mode 100644 index 00000000..8abe6379 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1305400 @@ -0,0 +1,100 @@ + +qmp-version of memsave makes a zero filled dump + +calling the memsave function through hmp and qmp makes a different results. it happened because hmp_memsave calls synchronization of cpu, but qmp_marshal_input_memsave does not. so virDomainMemoryPeek (libvirt api) does not work correctly + +1) hmp: +void hmp_memsave(Monitor *mon, const QDict *qdict) +{ + uint32_t size = qdict_get_int(qdict, "size"); + const char *filename = qdict_get_str(qdict, "filename"); + uint64_t addr = qdict_get_int(qdict, "val"); + Error *errp = NULL; + + qmp_memsave(addr, size, filename, true, <<<< monitor_get_cpu_index() >>>, &errp); + hmp_handle_error(mon, &errp); +} +int monitor_get_cpu_index(void) +{ + CPUState *cpu = ENV_GET_CPU(<<< mon_get_cpu >>>()); + return cpu->cpu_index; +} +static CPUArchState *mon_get_cpu(void) +{ + if (!cur_mon->mon_cpu) { + monitor_set_cpu(0); + } + <<< cpu_synchronize_state(cur_mon->mon_cpu); >>> + return cur_mon->mon_cpu->env_ptr; +} + +2) qmp +int qmp_marshal_input_memsave(Monitor *mon, const QDict *qdict, QObject **ret) +{ + Error *local_err = NULL; + Error **errp = &local_err; + QDict *args = (QDict *)qdict; + QmpInputVisitor *mi; + QapiDeallocVisitor *md; + Visitor *v; + int64_t val; + int64_t size; + char * filename = NULL; + bool has_cpu_index = false; + int64_t cpu_index; + + mi = qmp_input_visitor_new_strict(QOBJECT(args)); + v = qmp_input_get_visitor(mi); + visit_type_int(v, &val, "val", errp); + visit_type_int(v, &size, "size", errp); + visit_type_str(v, &filename, "filename", errp); + visit_start_optional(v, &has_cpu_index, "cpu-index", errp); + if (has_cpu_index) { + visit_type_int(v, &cpu_index, "cpu-index", errp); + } + visit_end_optional(v, errp); + qmp_input_visitor_cleanup(mi); + + if (error_is_set(errp)) { + goto out; + } + <<< qmp_memsave(val, size, filename, has_cpu_index, cpu_index, errp); >>> + +out: + md = qapi_dealloc_visitor_new(); + v = qapi_dealloc_get_visitor(md); + visit_type_int(v, &val, "val", NULL); + visit_type_int(v, &size, "size", NULL); + visit_type_str(v, &filename, "filename", NULL); + visit_start_optional(v, &has_cpu_index, "cpu-index", NULL); + if (has_cpu_index) { + visit_type_int(v, &cpu_index, "cpu-index", NULL); + } + visit_end_optional(v, NULL); + qapi_dealloc_visitor_cleanup(md); + + if (local_err) { + qerror_report_err(local_err); + error_free(local_err); + return -1; + } + return 0; +} + +how to reproduce: + +1) run qemu as it makes a libvirtd +./qemu-system-x86_64 -name gentoo -machine pc-i440fx-1.7,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 135b3e47-43ca-bc68-e23b-354a2f62a023 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=./gentoo.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -kernel ./bzImage -append root="/dev/vda2 vga=38f" -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=./gentoo.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=./install-amd64-minimal-20140320.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -vnc 127.0.0.1:2 -monitor stdio + +2) attach to qemu through qmp-shell (taken from qemu sources) +python ./qmp-shell ./gentoo.monitor + +3) make some commands in sequence +(qmp-shell) memsave memsave val=-2130706432 size=100 filename=./test01 +(stdio monitor) memsave 0xffffffff81000000 100 ./test02 +(qmp-shell) memsave memsave val=-2130706432 size=100 filename=./test03 + +result: +test01 - zero filled +test02 - right +test03 - right \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1307225 b/results/classifier/gemma3:12b/hypervisor/1307225 new file mode 100644 index 00000000..3324d863 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1307225 @@ -0,0 +1,23 @@ + +Running a virtual machine on a Haswell system produces machine check events + +I'm running a virtual Windows SBS 2003 installation on a Xeon E3 Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the latest stable version on Gentoo). I got a lot of machine check events ("mce: [Hardware Error]: Machine check events logged") in dmesg that always looked like (using mcelog): + +Hardware event. This is not a software error. +MCE 7 +CPU 2 BANK 0 +TIME 1390267908 Tue Jan 21 02:31:48 2014 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 6 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + +I found this discussion on the vmware community: https://communities.vmware.com/thread/452344 + +It seems that this is (at least partly) caused by the Qemu machine. I switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With this version, the errors almost disappeared, but from time to time, I still get machine check events. Anyways, they so not seem to affect neither the vm, nor the host. + +I created the virtual machine on an older Core 2 Duo machine and ran it for several weeks without a single error message, so I think this is actually some problem with the Haswell architecture. The errors didn't show up until I copied the virtual machine to my new machine. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1308341 b/results/classifier/gemma3:12b/hypervisor/1308341 new file mode 100644 index 00000000..c09748c1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1308341 @@ -0,0 +1,9 @@ + +Multiple CPUs causes blue screen on Windows guest (14.04 regression) + +Configuring a Windows 7 guest using more than one CPU cases the guest to fail. This happens after a few hours after guest boot. This is the error on the blue screen: +"A clock interrupt was not received on a secondary processor within the allocated time interval" + +After resetting, the guest will never boot and a new bluescreen with the error "STOP: 0x0000005c" appears. Shutting down the guest completely and restarting it will allow it to boot and run for a few hours again. + +The guest was created using virt-manager. The error happens with or without virtio devices. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1317603 b/results/classifier/gemma3:12b/hypervisor/1317603 new file mode 100644 index 00000000..702379ab --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1317603 @@ -0,0 +1,23 @@ + +qemu-system-ppc does not terminate on VM exit + +When a VM is created for a p4080-e500mc ; the VM can not be rebooted or terminated. + +The qemu-system-ppc process must be killed. + +ProblemType: Bug +DistroRelease: Ubuntu 14.04 +Package: qemu-system-ppc 2.0.0~rc1+dfsg-0ubuntu3.1 +ProcVersionSignature: Ubuntu 3.13.0-24.46-powerpc-e500mc 3.13.9 +Uname: Linux 3.13.9+ ppc +ApportVersion: 2.14.1-0ubuntu3 +Architecture: powerpc +Date: Thu May 8 12:20:57 2014 +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu +UpgradeStatus: Upgraded to trusty on 2014-04-29 (9 days ago) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1325 b/results/classifier/gemma3:12b/hypervisor/1325 new file mode 100644 index 00000000..0038ab60 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1325 @@ -0,0 +1,82 @@ + +c++: internal compiler error: Segmentation fault signal terminated program cc1plus when running in qemu-aarch64-static chroot on x86_64 +Description of problem: +After a moment of compiling the `src/emoji/Provider.cpp` file, `cc1plus` (I assume the compiler program itself) throws a segfault when running in the emulated chroot environment. The error is shown below. +``` +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +c++: internal compiler error: Segmentation fault signal terminated program cc1plus +Please submit a full bug report, with preprocessed source (by using -freport-bug). +See <https://github.com/archlinuxarm/PKGBUILDs/issues> for instructions. +``` + +This does not happen if you enter the chroot environment on a real ARM device (like a Raspberry PI 3 or 4 or PinePhone). The ARM device does not need to have `qemu-user-static`, nor `qemu-user-static-binfmt` installed because it does not need to emulate an aarch64 CPU. +Steps to reproduce: +There are two ways to replicate this. Either use (1) my preconfigured ARM chroot or (2) setup the chroot environment yourself. These instructions assume you are running on Arch Linux (x86_64). +1. You can use my aarch64 chroot environment provided. (This is the easy way) + - 1) Clone the repo I provided and then change into that directory. +```bash +git clone https://github.com/i3Craig/Temp-aarch64-chroot-for-nheko-compile-issues-in-qemu.git +cd Temp-aarch64-chroot-for-nheko-compile-issues-in-qemu +``` + - 2) On your PC, install `qemu-user-static` and `qemu-user-static-binfmt` and `arch-install-scripts`. This will allow us to `chroot` into the Arch Linux ARM image (technically `chroot` will work since we don't need to use `pacman` for anything with this method, so you could skip `arch-install-scripts` if you prefer). `sudo pacman -S qemu-user-static qemu-user-static-binfmt arch-install-scripts`. + - 3) I put the chroot environment in a state where you can simply run the following command to build the one file that fails. Run the following command. + ```bash +sudo chroot chroot/ /usr/bin/c++ -DFMT_SHARED -DGSTREAMER_AVAILABLE -DNHEKO_DBUS_SYS -DQAPPLICATION_CLASS=QApplication -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB -DXCB_AVAILABLE -Dnheko_EXPORTS -I/home/builder/packages/nheko/src/build -I/home/builder/packages/nheko/src/nheko-0.10.2 -I/home/builder/packages/nheko/src/build/nheko_autogen/include -I/home/builder/packages/nheko/src/nheko-0.10.2/src -I/home/builder/packages/nheko/src/nheko-0.10.2/includes -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/blurhash -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/cpp-httplib-0.5.12 -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/SingleApplication-3.3.2 -isystem /usr/include/qt -isystem /usr/include/qt/QtDBus -isystem /usr/include/qt/QtCore -isystem /usr/lib/qt/mkspecs/linux-g++ -isystem /usr/include/qt/QtWidgets -isystem /usr/include/qt/QtGui -isystem /usr/include/qt/QtSvg -isystem /usr/include/qt/QtConcurrent -isystem /usr/include/qt/QtMultimedia -isystem /usr/include/qt/QtNetwork -isystem /usr/include/qt/QtQml -isystem /usr/include/qt/QtQuickControls2 -isystem /usr/include/qt/QtQuick -isystem /usr/include/qt/QtQmlModels -isystem /usr/include/qt/QtQuickWidgets -isystem /usr/include/gstreamer-1.0 -isystem /usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem /usr/include/sysprof-4 -isystem /usr/include/orc-0.4 -isystem /usr/include/libmount -isystem /usr/include/blkid -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Wextra -pedantic -fsized-deallocation -fdiagnostics-color=always -Wunreachable-code -Wno-attributes -fPIE -fPIC -DSPDLOG_SHARED_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -pthread -std=gnu++17 -Winvalid-pch -include /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/cmake_pch.hxx -MD -MT /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o -MF /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o.d -o /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o -c /home/builder/packages/nheko/src/nheko-0.10.2/src/emoji/Provider.cpp + ``` +- 4) The above command will fail with a segfault error. If you copy your `chroot` over to a real ARM device (like an Raspberry PI 3 or 4 or PinePhone) and run the compile command from step (3), it will be successful. This suggests that everything is setup correctly, but there is a bug in QEMU that causes the c++ compiler to fail. + +2. You can download an Arch Linux ARM image from archlinuxarm.org and chroot into that. Then attempt to build the `nheko` AUR package. (This way requires extra work, but you can use this if you don't trust my chroot archive). + - 1) Download Arch Linux ARM to your X86_64 PC. The Raspberry PI 3/4 image should work. `http://os.archlinuxarm.org/os/ArchLinuxARM-rpi-aarch64-latest.tar.gz`. Signatures are available on archlinuxarm.org. + - 2) Extract the tar archive: `mkdir chroot; sudo tar -xf ArchLinuxARM-rpi-aarch64-latest.tar.gz -C chroot` (this will extract to the `chroot` folder in your current working directory. + - 3) On your PC, install `qemu-user-static` and `qemu-user-static-binfmt` and `arch-install-scripts`. This will allow us to `chroot` into the Arch Linux ARM image (using the `arch-chroot` because we will need to install packages with pacman in the chroot environment). `sudo pacman -S qemu-user-static qemu-user-static-binfmt arch-install-scripts`. + - 4) Now, we can bindmount the `chroot` directory to itself so `arch-chroot` is happy. `sudo mount --bind chroot/ chroot/` + - 5) Enter the chroot: `sudo arch-chroot chroot/` + - 6) At this point, we need to get our build environment setup. Let's start by installing `git`, `base-devel`, `screen` and `vim`. `pacman -S git base-devel screen vim`. I use screen to have one terminal for the root user to install stuff and one for the `builder` user that we will create for building packages as `makepkg` does not particularly like to run as root. + - 7) Add the builder user and create its home folder: `useradd builder; mkdir /home/builder; chown builder:builder /home/builder`. + - 8) You could maybe use an AUR helper to build the following packages, but they don't have the 'aarch64' flag, so they will throw an error when you try to compile them. Thus, I use `makepkg` manually with the `--ignorearch` flag to ignore the architecture of the chroot environment (they are fully compatible with aarch64, just not marked as such). Thus, run `su -l builder` to switch to the builder user, `mkdir packages` to create the packages folder, and then clone the following AUR packages into this folder and build them: `coeurl lmdbxx mtxclient nheko tweeny`. These are dependencies for `nheko`. The process is `git clone https://aur.archlinux.org/<PACKAGENAME>.git`, then `cd PACKAGENAME`, then `makepkg --ignorearch`, then (as the root user in the chroot environment - can use sudo if you set it up) `pacman -U PACKAGENAME.PACKAGEVERSION.pkg.tar.xz` (you can type the package name and then use tab to autocomplete the exact package name). They will all compile just fine and install correctly. + - 9) Now, do the same for the AUR package `nheko`. Notice that it will start to compile, but the error shown above will be printed on the screen after a while. If you copy your `chroot` over to a real ARM device (like an Raspberry PI 3 or 4 or PinePhone) and `arch-chroot` into it and attempt the compile again, it will be successful. This suggests that everything is setup correctly, but there is a bug in qemu that causes the c++ compiler to fail. This is known to break in nheko version `0.10.2-1`. You can get to this by running `git checkout d83124fbffe86d7f875bf8e56834ae98cc21160c` after you clone the `nheko` AUR build script. This is the current latest version as of writing this, but this may change in the future and the bug may no longer show up. If it doesn't, run that `git checkout` command. +Additional information: +After using the `-strace` option in `qemu-aarch64-static` (which has to be copied from the host system to the chroot for this to work: `sudo cp /usr/bin/qemu-aarch64-static chroot/usr/bin/qemu-aarch64-static`), I determined that `c++` was running `/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/cc1plus`, which segfaulted. Note: have to run `sudo arch-chroot chroot/ /usr/bin/qemu-aarch64-static -strace <PUT LONG C++ COMPILE COMMAND HERE>`. +After manually running the `cc1plus` command with the `-strace` option outlined above, I get the following strace, which doesn't seem particularly interesting. +``` +1 brk(0x000000000320a000) = 0x000000000320a000 +1 brk(0x000000000324a000) = 0x000000000324a000 +1 brk(0x00000000032ca000) = 0x00000000032ca000 +1 brk(0x00000000033ca000) = 0x00000000033ca000 +1 brk(0x00000000035ca000) = 0x00000000035ca000 +1 brk(0x00000000031ca000) = 0x00000000031ca000 +1 mmap(NULL,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520bc3000 +1 brk(0x000000000320a000) = 0x000000000320a000 +1 brk(0x000000000324a000) = 0x000000000324a000 +1 brk(0x00000000032ca000) = 0x00000000032ca000 +1 brk(0x00000000033ca000) = 0x00000000033ca000 +1 brk(0x00000000035ca000) = 0x00000000035ca000 +1 mmap(NULL,4198400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520be3000 +1 brk(0x00000000031ca000) = 0x00000000031ca000 +1 munmap(0x0000005520be3000,4198400) = 0 +1 brk(0x000000000320a000) = 0x000000000320a000 +1 brk(0x000000000324a000) = 0x000000000324a000 +1 brk(0x00000000032ca000) = 0x00000000032ca000 +1 brk(0x00000000033ca000) = 0x00000000033ca000 +1 brk(0x00000000035ca000) = 0x00000000035ca000 +1 brk(0x00000000039ca000) = 0x00000000039ca000 +1 brk(0x00000000031ca000) = 0x00000000031ca000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520fe4000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055211e4000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055213e4000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055215e4000 +1 brk(0x00000000031eb000) = 0x00000000031eb000 +1 mmap(NULL,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055217e4000 +1 brk(0x0000000003214000) = 0x0000000003214000 +1 brk(0x0000000003274000) = 0x0000000003274000 +1 brk(0x0000000003295000) = 0x0000000003295000 +1 brk(0x0000000003318000) = 0x0000000003318000 +1 brk(0x0000000003339000) = 0x0000000003339000 +1 brk(0x000000000335a000) = 0x000000000335a000 +--- SIGSEGV {si_signo=SIGSEGV, si_code=2, si_addr=0x0000005500000ff0} --- +--- SIGSEGV {si_signo=SIGSEGV, si_code=2, si_addr=0x0000005500000ff0} --- +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +``` + + +I haven't encountered this bug when compiling any other programs, which is good. However, it mea diff --git a/results/classifier/gemma3:12b/hypervisor/1331334 b/results/classifier/gemma3:12b/hypervisor/1331334 new file mode 100644 index 00000000..ac9a6633 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1331334 @@ -0,0 +1,4 @@ + +driftfix=none and migration on Win7 guest causes time to go 10 times as fast + +With -rtc base=localtime,clock=host,driftfix=none on a Win7 guest, stopping it with migration and then starting it again about 1 hour later makes the guest time go 10 times as fast as real time until Windows is rebooted. I have tried qith qemu-2.0.0 and the problem still exists there. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1337 b/results/classifier/gemma3:12b/hypervisor/1337 new file mode 100644 index 00000000..503a6b62 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1337 @@ -0,0 +1,17 @@ + +Incorrect warnings when using vhost without numa +Description of problem: +Part A: Misleading error message. Running the above command for any architecture fails to initialize vhost, and prints the following, incorrect advice +``` +qemu-system-mips: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on +qemu-system-mips: vhost_set_mem_table failed: Invalid argument (22) +qemu-system-mips: Error starting vhost: 22 +``` + +Since the command line already contains `-object memory-backend-file,id=mem1,mem-path=/tmp/mem,size=256M,share=on` this error message should not be printed. For x86_64, this can be resolved by adding `-numa node,memdev=mem0` to the command line. As such, I think this error message should instead guide a user to adding that argument. + +Part B: No documented configuration to run vhost-user for machines that don't support numa. +The mips malta machine does not support the `-numa` flag. It is unclear if this means that `vhost` cannot be used with this platform or if a non-numa configuration with a memory-backend-file can be used. +Steps to reproduce: +1. Run `vhost-user-vsock --socket=/tmp/vhost4.socket --uds-path=/tmp/foo` from https://github.com/rust-vmm/vhost-device. +1. Run the above QEMU command diff --git a/results/classifier/gemma3:12b/hypervisor/1341032 b/results/classifier/gemma3:12b/hypervisor/1341032 new file mode 100644 index 00000000..e8f20a43 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1341032 @@ -0,0 +1,12 @@ + +no-shutdown does not fire SHUTDOWN event for some guests + +Currently using: qemu-x86_64 version 2.0.0 +Steps to reproduce: Create virtual machine with the arguments -no-shutdown, such as used by libvirt. Attach to the json event system. Load a guest such as Ubuntu 14.04 and run the 'halt' command. Guest ceases to execute, qemu freezes CPUs however no SHUTDOWN event is fired to the monitor. + +Now load a guest such as finnix or Debian 7. Run the same sequence of steps and note that the SHUTDOWN event is fired to the monitor. + +This seems like a qemu bug as the execution of the guest has ceased. + +Thanks +Michael \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1354727 b/results/classifier/gemma3:12b/hypervisor/1354727 new file mode 100644 index 00000000..27ebcc93 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1354727 @@ -0,0 +1,11 @@ + +build error with GCC 4.9 + +% gcc --version +gcc (GCC) 4.9.1 + +latest development version on git + +xen-hvm.c: In function ‘xen_hvm_init’: +xen-hvm.c:1008:41: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn); \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1369 b/results/classifier/gemma3:12b/hypervisor/1369 new file mode 100644 index 00000000..611ed458 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1369 @@ -0,0 +1,2 @@ + +'make vm-build-openbsd' fails to notice when QEMU fails to start diff --git a/results/classifier/gemma3:12b/hypervisor/137 b/results/classifier/gemma3:12b/hypervisor/137 new file mode 100644 index 00000000..2315baad --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/137 @@ -0,0 +1,2 @@ + +Incompatibility with future VTE will breaks qemu monitor (::commit signal) diff --git a/results/classifier/gemma3:12b/hypervisor/1379 b/results/classifier/gemma3:12b/hypervisor/1379 new file mode 100644 index 00000000..77fde7a5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1379 @@ -0,0 +1,2 @@ + +dump memory read write operations diff --git a/results/classifier/gemma3:12b/hypervisor/1380 b/results/classifier/gemma3:12b/hypervisor/1380 new file mode 100644 index 00000000..6b889d7c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1380 @@ -0,0 +1,5 @@ + +vdagent is not working properly after live migration +Additional information: +when validating on windows server 2016 Datacenter Evaluation, i found that if vdagent process or vdservice is restarted, copy/paste from host to guest or reverse will work again. i am wondering if we should send something(eg, a event?) to guest to let it reopen the port after live migration? + diff --git a/results/classifier/gemma3:12b/hypervisor/1381 b/results/classifier/gemma3:12b/hypervisor/1381 new file mode 100644 index 00000000..d3a92891 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1381 @@ -0,0 +1,4 @@ + +plugins: plugin_mem_cbs is not consistently NULL'ed when returning from execution +Description of problem: +This is an invariant that we should have been checking for; when returning from execution, cpu->plugin_mem_cbs should be NULL. Otherwise we open a door for a use-after-free; admittedly this door isn't that large (it requires a tb_flush to occur while we have the dangling plugin_mem_cbs), but at least one plugin user has encountered this problem: https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg02703.html diff --git a/results/classifier/gemma3:12b/hypervisor/1383 b/results/classifier/gemma3:12b/hypervisor/1383 new file mode 100644 index 00000000..61d22237 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1383 @@ -0,0 +1,2 @@ + +Pentium Pro cpuid capabilities are wrong, resulting in wrong definition of athlon and others diff --git a/results/classifier/gemma3:12b/hypervisor/1392 b/results/classifier/gemma3:12b/hypervisor/1392 new file mode 100644 index 00000000..75609cde --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1392 @@ -0,0 +1,15 @@ + +qemu 7.2.0 almalinux 9.1 guest vda io error +Description of problem: +after update the qemu from 7.1.0 to 7.2.0 guest almalinux 9.1 have disk io error ,log : +```log +Dec 24 00:17:39 rlh1 kernel: I/O error, dev vda, sector 109770720 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 +Dec 24 00:17:42 rlh1 kernel: dm-0: writeback error on inode 33585275, offset 4096, sector 33359840 +Dec 24 00:17:42 rlh1 kernel: I/O error, dev vda, sector 109770776 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 +Dec 24 00:17:42 rlh1 kernel: dm-0: writeback error on inode 33585275, offset 4096, sector 33359896 +Dec 24 00:17:42 rlh1 kernel: I/O error, dev vda, sector 109770832 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 +``` + +then I switch back to version 7.1.0 it work as normal +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1395 b/results/classifier/gemma3:12b/hypervisor/1395 new file mode 100644 index 00000000..d36975a9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1395 @@ -0,0 +1,157 @@ + +qemu-system-riscv32 cpu_transaction_failed cause Infinite loop when write mstatus ~"target: riscv" +Description of problem: +I wanna run FreeRTOS riscv, and use the FreeRTOS/Demo/RISC-V-Qemu-virt_GCC/Makefile to build elf.\ +When qemu execute to write mstatus as 0x1888(enable Interrupt, MIE:1, MIP:1, MPP:3), there is no response.\ +https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/RISC-V/portASM.S\ +line 274: csrrw x0, mstatus, x5 /* Interrupts enabled from here! */\ +opcode is hex 30029073\n +I use pstack to trace qemu thread, there is only one thread is active, and cpu loading is 100%.\ +then I use gdb attatch <pid> to trace the active thread, and it has a loop\ +cpu_loop_exit call siglongjmp and back to sigsetjmp in cpu_exec (cpu=cpu@entry=0x55e2294e4070) at ../accel/tcg/cpu-exec.c:936 +Steps to reproduce: +1.download FreeRTOS and build FreeRTOS/Demo/RISC-V-Qemu-virt_GCC\ +2.run qemu with gdb\ +3.hang when writing mstatus +Additional information: +I find that my issue occur when mtvec is zero and timer interrupt occur when writing mstatus(riscv_cpu_do_interrupt)\ +Although it should jump to 0x0 rather then hanging in while loop.\ +expected flow :cpu_handle_interrupt->check_for_breakpoints->break\ +actually flow: cpu_handle_interrupt->check_for_breakpoints->infinite loop\ +Qemu build command: +``` +./configure --target-list=riscv32-softmmu && make +``` + +pstack for qemu (only need to debug Thread 3) +``` +Thread 3 (Thread 0x7f83af6d3640 (LWP 5093) "qemu-system-ris"): +#0 0x000055cb31b1769f in riscv_cpu_exec_interrupt () +#1 0x0000000000000000 in () +Thread 2 (Thread 0x7f83b0119640 (LWP 5092) "qemu-system-ris"): +#0 0x00007f83b0400a3d in syscall () at /lib/x86_64-linux-gnu/libc.so.6 +#1 0x000055cb31e0bd52 in qemu_event_wait () +#2 0x0000000000000000 in () +Thread 1 (Thread 0x7f83b011ac00 (LWP 5090) "qemu-system-ris"): +#0 0x00007f83b03fae7e in ppoll () at /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007f83b0752500 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#2 0x000055cb33241b30 in () +#3 0x0000000000000005 in () +#4 0x0000000000000000 in () +``` +backtrace for the infinite loop +``` +(gdb) bt +#0 cpu_loop_exit (cpu=0x55e2294e4070) at ../accel/tcg/cpu-exec-common.c:65 +#1 0x000055e2274efde4 in cpu_loop_exit_restore (cpu=cpu@entry=0x55e2294e4070, pc=pc@entry=0) + at ../accel/tcg/cpu-exec-common.c:76 +#2 0x000055e22737fff1 in riscv_cpu_do_transaction_failed + (cs=0x55e2294e4070, physaddr=<optimized out>, addr=0, size=<optimized out>, access_type=MMU_INST_FETCH, mmu_idx=<optimized out>, attrs=..., response=2, retaddr=0) + at ../target/riscv/cpu_helper.c:1165 +#3 0x000055e2274fa4a7 in cpu_transaction_failed + (retaddr=0, response=2, attrs=..., mmu_idx=3, access_type=MMU_INST_FETCH, size=<optimized out>, addr=0, physaddr=<optimized out>, cpu=0x55e2294e4070) at ../accel/tcg/cputlb.c:1344 +#4 io_readx + (env=env@entry=0x55e2294e53d0, full=full@entry=0x7fd90c029410, mmu_idx=3, addr=addr@entry=0, retaddr=retaddr@entry=0, access_type=access_type@entry=MMU_INST_FETCH, op=MO_16) + at ../accel/tcg/cputlb.c:1380 +#5 0x000055e2274fba28 in load_helper + (full_load=<optimized out>, code_read=true, op=MO_16, retaddr=0, oi=19, addr=0, env=0x55e2294e53d0) at ../accel/tcg/cputlb.c:1970 +#6 full_lduw_code (env=env@entry=0x55e2294e53d0, addr=addr@entry=0, oi=19, retaddr=0) + at ../accel/tcg/cputlb.c:2606 +#7 0x000055e22750827b in cpu_lduw_code (env=env@entry=0x55e2294e53d0, addr=addr@entry=0) + at ../accel/tcg/cputlb.c:2612 +#8 0x000055e2274f87fa in translator_lduw + (env=env@entry=0x55e2294e53d0, db=db@entry=0x7fd913dfe5a0, pc=0) + at ../accel/tcg/translator.c:216 +#9 0x000055e2273e423a in riscv_tr_translate_insn (dcbase=0x7fd913dfe5a0, cpu=<optimized out>) + at ../target/riscv/translate.c:1158 +#10 0x000055e2274f83d3 in translator_loop + (cpu=cpu@entry=0x55e2294e4070, tb=tb@entry=0x7fd91c000240 <code_gen_buffer+531>, max_insns=<optim + ized out>, pc=pc@entry=0, host_pc=host_pc@entry=0x55e2274efe74 <tb_htable_lookup+84>, ops=ops@entry=0x55e227a75c80 <riscv_tr_ops>, db=0x7fd913dfe5a0) at ../accel/tcg/translator.c:96 +#11 0x000055e227411760 in gen_intermediate_code + (cs=cs@entry=0x55e2294e4070, tb=tb@entry=0x7fd91c000240 <code_gen_buffer+531>, max_insns=<optimized out>, pc=pc@entry=0, host_pc=host_pc@entry=0x55e2274efe74 <tb_htable_lookup+84>) + at ../target/riscv/translate.c:1240 +#12 0x000055e2274f6954 in setjmp_gen_code + (env=env@entry=0x55e2294e53d0, tb=tb@entry=0x7fd91c000240 <code_gen_buffer+531>, pc=pc@entry=0, host_pc=0x55e2274efe74 <tb_htable_lookup+84>, max_insns=max_insns@entry=0x7fd913dfe744, ti=<optimized out>) at ../accel/tcg/translate-all.c:761 +#13 0x000055e2274f7294 in tb_gen_code + (cpu=cpu@entry=0x55e2294e4070, pc=0, cs_base=0, flags=1085443, cflags=<optimized out>, + cflags@entry=-16777216) at ../accel/tcg/translate-all.c:841 +#14 0x000055e2274f10cf in cpu_exec (cpu=cpu@entry=0x55e2294e4070) at ../accel/tcg/cpu-exec.c:1006 +#15 0x000055e22750a904 in tcg_cpus_exec (cpu=cpu@entry=0x55e2294e4070) + at ../accel/tcg/tcg-accel-ops.c:69 +#16 0x000055e22750aa57 in mttcg_cpu_thread_fn (arg=arg@entry=0x55e2294e4070) + at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#17 0x000055e227674b21 in qemu_thread_start (args=<optimized out>) + at ../util/qemu-thread-posix.c:505 +#18 0x00007fd9611a9b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#19 0x00007fd96123ba00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` + +disassembly code +``` +80001ac6 <xPortStartFirstTask>: +80001ac6: 85c1a103 lw sp,-1956(gp) # 800809fc <pxCurrentTCB> +80001aca: 4102 lw sp,0(sp) +80001acc: 4082 lw ra,0(sp) +80001ace: 43c2 lw t2,16(sp) +80001ad0: 4452 lw s0,20(sp) +80001ad2: 44e2 lw s1,24(sp) +80001ad4: 4572 lw a0,28(sp) +80001ad6: 5582 lw a1,32(sp) +80001ad8: 5612 lw a2,36(sp) +80001ada: 56a2 lw a3,40(sp) +80001adc: 5732 lw a4,44(sp) +80001ade: 57c2 lw a5,48(sp) +80001ae0: 5852 lw a6,52(sp) +80001ae2: 58e2 lw a7,56(sp) +80001ae4: 5972 lw s2,60(sp) +80001ae6: 4986 lw s3,64(sp) +80001ae8: 4a16 lw s4,68(sp) +80001aea: 4aa6 lw s5,72(sp) +80001aec: 4b36 lw s6,76(sp) +80001aee: 4bc6 lw s7,80(sp) +80001af0: 4c56 lw s8,84(sp) +80001af2: 4ce6 lw s9,88(sp) +80001af4: 4d76 lw s10,92(sp) +80001af6: 5d86 lw s11,96(sp) +80001af8: 5e16 lw t3,100(sp) +80001afa: 5ea6 lw t4,104(sp) +80001afc: 5f36 lw t5,108(sp) +80001afe: 5fc6 lw t6,112(sp) +80001b00: 52d6 lw t0,116(sp) +80001b02: 0007f317 auipc t1,0x7f +80001b06: ea232303 lw t1,-350(t1) # 800809a4 <pxCriticalNesting> +80001b0a: 00532023 sw t0,0(t1) +80001b0e: 52e6 lw t0,120(sp) +80001b10: 02a1 addi t0,t0,8 +80001b12: 30029073 csrw mstatus,t0 <--- hang on this line +80001b16: 42a2 lw t0,8(sp) +80001b18: 4332 lw t1,12(sp) +80001b1a: 07c10113 addi sp,sp,124 +80001b1e: 8082 ret +``` + +``` +(gdb) bt +#0 cpu_loop_exit (cpu=cpu@entry=0x564cd884b070) at ../accel/tcg/cpu-exec-common.c:65 +#1 0x0000564cd6685631 in helper_lookup_tb_ptr (env=0x564cd884c3d0) at ../accel/tcg/cpu-exec.c:400 +#2 0x00007f55dc00014c in code_gen_buffer () +#3 0x0000564cd668521b in cpu_tb_exec + (cpu=cpu@entry=0x564cd884b070, itb=itb@entry=0x7f55dc000040 <code_gen_buffer+19>, tb_exit=tb_exit@entry=0x7f56235f67ec) at ../accel/tcg/cpu-exec.c:438 +#4 0x0000564cd6685cfb in cpu_loop_exec_tb + (tb_exit=0x7f56235f67ec, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7f55dc000040 <code_gen_buffer+19>, cpu=0x564cd884b070) at ../accel/tcg/cpu-exec.c:868 +#5 cpu_exec (cpu=cpu@entry=0x564cd884b070) at ../accel/tcg/cpu-exec.c:1032 +#6 0x0000564cd669f904 in tcg_cpus_exec (cpu=cpu@entry=0x564cd884b070) + at ../accel/tcg/tcg-accel-ops.c:69 +#7 0x0000564cd669fa57 in mttcg_cpu_thread_fn (arg=arg@entry=0x564cd884b070) + at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#8 0x0000564cd6809b21 in qemu_thread_start (args=<optimized out>) + at ../util/qemu-thread-posix.c:505 +#9 0x00007f562429ab43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#10 0x00007f562432ca00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` + +I also build a very simple elf for qemu-virt-platform, just contain boot-loader and write mstatus as 0x1888, it can't reproduce.\ +I also build different qemu version such v6.0.0, it still can reproduce.\ +I has modify the march to the most simple arch:rv32i, is still can reproduce. + +~"target: riscv" diff --git a/results/classifier/gemma3:12b/hypervisor/1396 b/results/classifier/gemma3:12b/hypervisor/1396 new file mode 100644 index 00000000..16443e1d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1396 @@ -0,0 +1,4 @@ + +Is it possible to emulate QEMU 64 Bit on Windows? +Description of problem: +Is it possible to emulate 64 Bit OS on Windows QEMU version? I'm trying to emulate ESXi image but the ESXi says it can only start 32 bit VM's. When I try to start a 64 bit VM from the ESXi I get the error `Task failed on server: Module 'CPUID' power on failed. `. diff --git a/results/classifier/gemma3:12b/hypervisor/1396052 b/results/classifier/gemma3:12b/hypervisor/1396052 new file mode 100644 index 00000000..f9a62df1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1396052 @@ -0,0 +1,65 @@ + +migration failed when running BurnInTest in guest + +Hi, +I found a live migration problem and have found out the reason, but I can't fix it up myself. I really need help. +When live migration vm and it's block device in save time, it will occur probabilistic . + +Step: +1. start a windows vm,and run burnInTest(it will write dirty data to block device in migration) +2. migrate vm with it's block device. +3. a few minutes later, dest vm was killed and migration will be failed (probabilistic ) + +Reason: + when migraion start, in source host libvirt will send command to qemu,and qemu will call mirror_run coroutine to copy blcok device data to dest vm block device. mirror_run running in qemu main thread. When this finished(actually it still running because in following steps,there may generate dirty data by vm), qemu will start migration_thread to migration ram and other device. + In dest vm, qemu will call "bdrv_invalidate_cache --> qcow2_invalidate_cache" function after vm read "QEMU_VM_EOF" byte. qcow2_invalidate_cache fuction call qcow2_close , in qcow2_close fuction set "s->l1_table = NULL" and then call qcow2_cache_flush fuction. In qcow2_cache_flush fuction will call "bdrv_flush-->bdrv_flush_co_entry-->bdrv_co_flush-->qemu_coroutine_yield". This will let itself back to mian loop. If source vm send block device dirty data to dest vm at this time, in dest vm will occur the following segmentation fault. + The primary reason is mirror_run and migration run in two thread. although qemu stopping vm before write "QEMU_VM_EOF" byte, it still can't ensure mirror_run coroutine do not write dirty data after migration thread sending "QEMU_VM_EOF" byte. + + +Program received signal SIGSEGV, Segmentation fault. +0x00007f90d250db24 in get_cluster_table (bs=0x7f90d493f500, offset=1832189952, new_l2_table=0x7f8fbd6faa88, + new_l2_index=0x7f8fbd6faaa0) at block/qcow2-cluster.c:573 +573 l2_offset = s->l1_table[l1_index] & L1E_OFFSET_MASK; +(gdb) bt +#0 0x00007f90d250db24 in get_cluster_table (bs=0x7f90d493f500, offset=1832189952, new_l2_table=0x7f8fbd6faa88, + new_l2_index=0x7f8fbd6faaa0) at block/qcow2-cluster.c:573 +#1 0x00007f90d250e577 in handle_copied (bs=0x7f90d493f500, guest_offset=1832189952, host_offset=0x7f8fbd6fab18, + bytes=0x7f8fbd6fab20, m=0x7f8fbd6fabc8) at block/qcow2-cluster.c:927 +#2 0x00007f90d250ef45 in qcow2_alloc_cluster_offset (bs=0x7f90d493f500, offset=1832189952, num=0x7f8fbd6fabfc, + host_offset=0x7f8fbd6fabc0, m=0x7f8fbd6fabc8) at block/qcow2-cluster.c:1269 +#3 0x00007f90d250445f in qcow2_co_writev (bs=0x7f90d493f500, sector_num=3578496, remaining_sectors=2040, + qiov=0x7f8fbd6fae90) at block/qcow2.c:1171 +#4 0x00007f90d24d4764 in bdrv_aligned_pwritev (bs=0x7f90d493f500, req=0x7f8fbd6facd0, offset=1832189952, bytes=1044480, + qiov=0x7f8fbd6fae90, flags=0) at block.c:3321 +#5 0x00007f90d24d4d21 in bdrv_co_do_pwritev (bs=0x7f90d493f500, offset=1832189952, bytes=1044480, qiov=0x7f8fbd6fae90, + flags=0) at block.c:3447 +#6 0x00007f90d24d3115 in bdrv_rw_co_entry (opaque=0x7f8fbd6fae10) at block.c:2710 +#7 0x00007f90d24d31e7 in bdrv_prwv_co (bs=0x7f90d493f500, offset=1832189952, qiov=0x7f8fbd6fae90, is_write=true, flags=0) + at block.c:2746 +#8 0x00007f90d24d32eb in bdrv_rw_co (bs=0x7f90d493f500, sector_num=3578496, + buf=0x7f90d4e3d400 "\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312", <incomplete sequence \313>..., nb_sectors=2040, is_write=true, flags=0) at block.c:2776 +#9 0x00007f90d24d3429 in bdrv_write (bs=0x7f90d493f500, sector_num=3578496, + buf=0x7f90d4e3d400 "\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312", <incomplete sequence \313>..., nb_sectors=2040) at block.c:2810 +#10 0x00007f90d24cc2b5 in nbd_trip (opaque=0x7f90d4ba9aa0) at nbd.c:1191 +#11 0x00007f90d24e86fb in coroutine_trampoline (i0=-725586416, i1=32656) at coroutine-ucontext.c:118 +#12 0x00007f90d0449310 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#13 0x00007fff3fcfda10 in ?? () +#14 0x0000000000000000 in ?? () +(gdb) p bs +$1 = (BlockDriverState *) 0x7f90d493f500 +(gdb) p *s +$3 = {cluster_bits = 16, cluster_size = 65536, cluster_sectors = 128, l2_bits = 13, l2_size = 8192, l1_size = 40, + l1_vm_state_index = 40, csize_shift = 54, csize_mask = 255, cluster_offset_mask = 18014398509481983, + l1_table_offset = 196608, l1_table = 0x0, l2_table_cache = 0x7f90d493eee0, refcount_block_cache = 0x7f90d493ef30, + cluster_cache = 0x7f90d4a84350 "", cluster_data = 0x7f90ce4de010 "", cluster_cache_offset = 18446744073709551615, + cluster_allocs = {lh_first = 0x0}, refcount_table = 0x7f90d4a94360, refcount_table_offset = 65536, + refcount_table_size = 8192, free_cluster_index = 209420, free_byte_offset = 0, lock = {locked = true, queue = {entries = { + tqh_first = 0x0, tqh_last = 0x7f90d4942c60}}}, crypt_method = 0, crypt_method_header = 0, aes_encrypt_key = { + rd_key = {0 <repeats 60 times>}, rounds = 0}, aes_decrypt_key = {rd_key = {0 <repeats 60 times>}, rounds = 0}, + snapshots_offset = 0, snapshots_size = 0, nb_snapshots = 0, snapshots = 0x0, flags = 10338, qcow_version = 3, + use_lazy_refcounts = false, refcount_order = 4, discard_passthrough = {false, true, false, true, false}, + overlap_check = 127, incompatible_features = 0, compatible_features = 0, autoclear_features = 0, + unknown_header_fields_size = 0, unknown_header_fields = 0x0, unknown_header_ext = {lh_first = 0x0}, discards = { + tqh_first = 0x0, tqh_last = 0x7f90d4942ec8}, cache_discards = false} +(gdb) p s->l1_table +$4 = (uint64_t *) 0x0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1405 b/results/classifier/gemma3:12b/hypervisor/1405 new file mode 100644 index 00000000..c8c2435b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1405 @@ -0,0 +1,122 @@ + +linux-user: calling SYS_get_thread_area and SYS_get_thread_area has incorrent result on multithread environment +Description of problem: + +Steps to reproduce: +1. Compile test.out by Command and source code: +``` +gcc -m32 -g test.c -lpthread -o test.out +``` +``` +#include <sys/syscall.h> +#include <unistd.h> +#include <stdio.h> +#include <pthread.h> +#include <asm/ldt.h> + +static inline int set_thread_area( struct user_desc *ptr ) +{ + return syscall( SYS_set_thread_area, ptr ); +} + +static inline int get_thread_area( struct user_desc *ptr ) +{ + return syscall( SYS_get_thread_area, ptr ); +} + +static unsigned int entry_number; + +static void* start_routine(void* ptr) +{ + struct user_desc user_desc0 = { entry_number }; + struct user_desc user_desc1 = { entry_number }; + struct user_desc user_desc2 = { entry_number }; + get_thread_area(&user_desc0); + printf("child thread: %u\n", user_desc0.base_addr); + + user_desc1.base_addr = 2; + user_desc1.limit = 0xFFF; + user_desc1.seg_32bit = 1; + set_thread_area( &user_desc1 ); + + get_thread_area(&user_desc2); + printf("child thread: %u\n", user_desc2.base_addr); + return NULL; +} + +int main(void) { + struct user_desc user_desc0 = { -1 }, user_desc1 = { 0 }, user_desc2 = { 0 }; + user_desc0.seg_32bit = 1; + user_desc0.useable = 1; + set_thread_area( &user_desc0 ); + + entry_number = user_desc0.entry_number; + + user_desc1.entry_number = entry_number; + user_desc1.base_addr = 1; + user_desc1.limit = 0xFFF; + user_desc1.seg_32bit = 1; + set_thread_area( &user_desc1 ); + + pthread_t thread_id; + pthread_create(&thread_id, NULL, &start_routine, NULL); + pthread_join(thread_id, NULL); + + user_desc2.entry_number = entry_number; + get_thread_area(&user_desc2); + printf("main thread: %u\n", user_desc2.base_addr); // main thread: 1 + return 0; +} + ``` +2. Correct Result: +``` +child thread: 1 +child thread: 2 +main thread: 1 +``` +qemu-i386 Print Result: +``` +child thread: 1 +child thread: 2 +main thread: 2 +``` +Additional information: +patch for fix the bug: + +https://lists.nongnu.org/archive/html/qemu-devel/2023-02/msg02203.html + +CPUX86State::gdt::base on differect threads must have different vaules, but it points to same memory. +value of CPUX86State::gdt::base must be copied when clone thread. + +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/tls.c + +SYS_set_thread_area call do_set_thread_area in kernel, it set user_desc to different memroy area on differernt threads. tls_array is in thread local memory. + +``` +static void set_tls_desc(struct task_struct *p, int idx, + const struct user_desc *info, int n) +{ + struct thread_struct *t = &p->thread; + struct desc_struct *desc = &t->tls_array[idx - GDT_ENTRY_TLS_MIN]; + int cpu; + + /* + * We must not get preempted while modifying the TLS. + */ + cpu = get_cpu(); + + while (n-- > 0) { + if (LDT_empty(info) || LDT_zero(info)) + memset(desc, 0, sizeof(*desc)); + else + fill_ldt(desc, info); + ++info; + ++desc; + } + + if (t == ¤t->thread) + load_TLS(t, cpu); + + put_cpu(); +} +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1410 b/results/classifier/gemma3:12b/hypervisor/1410 new file mode 100644 index 00000000..d383d0c4 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1410 @@ -0,0 +1,15 @@ + +system_powerdown only works once +Description of problem: +When the guest is configured to sleep on power button events, something in the ACPI states are not restored coming out of resume. The first call to `system_powerdown` succeeds, but the second after waking the system is rejected in `acpi_pm1_evt_power_down()` since `ar->pm1.evt.en` is zero coming out of the resume path. + +There is probably something deeper (or perhaps in seabios?) since removing the test in that handler doesn't cause a second sleep either. +Steps to reproduce: + +1. Boot a guest configured to sleep when it receives a power button event +2. `system_powerdown` from the monitor to tell it to sleep +3. `info status` to verify that it is suspended +4. Wake the guest, either with `system_wakeup` or moving the mouse or something +5. `system_powerdown` has no effect +Additional information: +This is using qemu-7.2.0 built from source with a Windows 10 guest and IGD GPU+audio passthrough. diff --git a/results/classifier/gemma3:12b/hypervisor/1412 b/results/classifier/gemma3:12b/hypervisor/1412 new file mode 100644 index 00000000..058cb45a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1412 @@ -0,0 +1,6 @@ + +QEMU segfault (null pointer dereference) in sve_probe_page from ldff1* instructions +Description of problem: +After upgrading to QEMU v7.2.0 from v7.1.0, when executing any SVE ldff1* instructions with a faulting address, QEMU crashes due to a null pointer dereference at target/arm/sve_helper.c:5364 + +I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `full` is dereferenced before the `flags & TLB_INVALID_MASK` check at line 5369, and full is set to null by `probe_access_full` when `TLB_INVALID_MASK` is given. diff --git a/results/classifier/gemma3:12b/hypervisor/1416 b/results/classifier/gemma3:12b/hypervisor/1416 new file mode 100644 index 00000000..dbf1965d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1416 @@ -0,0 +1,6 @@ + +MTE tags are applied at page granularity (4K) instead of tag granularity (16) +Description of problem: +After upgrading to QEMU v7.2.0 from v7.1.0, when executing stg/ldg instructions on any address, QEMU behaves as if the instruction was executed on the page base of said address. + +I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `ptr_paddr` is changed to be calculated based on `CPUTLBEntryFull::phys_addr`, which contains the page base address, while beforehand it was calculated based on `host` which does have the page offset applied. diff --git a/results/classifier/gemma3:12b/hypervisor/1428958 b/results/classifier/gemma3:12b/hypervisor/1428958 new file mode 100644 index 00000000..60dce689 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1428958 @@ -0,0 +1,66 @@ + +random IO errors / data corruption in VMs (created and executed via virt-manager) + +I have recurring problems with VM installation and usage - data on VM disk gets corrupted at some point and it causes all sorts of problems - sometimes I cannot even install base system, other times some .so files are corrupt after isntallation, etc - totally random. +I use virt-manager to create and run VMs. I have also tried creating VMs via virt-install, result is identical. +If I use VirtualBox I have no such problems. +My OS is Fedora 20 upgraded to 21, qemu and libvirt are installed from Fedora official repos. + +Here's an example qemu command-line: +/usr/bin/qemu-system-x86_64 +-machine accel=kvm +-name fuel +-S +-machine pc-i440fx-2.1,accel=kvm,usb=off +-cpu SandyBridge,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+movbe,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme +-m 3142 +-realtime mlock=off +-smp 2,sockets=2,cores=1,threads=1 +-uuid 27693a46-7a50-4a3c-bcaf-bf061ba469ed +-no-user-config +-nodefaults +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fuel.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control +-rtc base=utc,driftfix=slew +-global kvm-pit.lost_tick_policy=discard +-no-hpet +-no-shutdown +-boot menu=on,strict=on +-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 +-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 +-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 +-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 +-device lsi,id=scsi0,bus=pci.0,addr=0xa +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 +-drive file=/home/virtual-disks/fuel.vdi,if=none,id=drive-virtio-disk0,format=vdi +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +-drive file=/home/dsutyagin/Downloads/iso/MirantisOpenStack-6.0.iso,if=none,id=drive-scsi0-0-0,readonly=on,format=raw +-device scsi-cd,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0,bootindex=2 +-netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0d:42:2d,bus=pci.0,addr=0x3 +-netdev tap,fd=25,id=hostnet1,vhost=on,vhostfd=26 +-device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:a4:8c:ef,bus=pci.0,addr=0x4 +-chardev pty,id=charserial0 +-device isa-serial,chardev=charserial0,id=serial0 +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/fuel.org.qemu.guest_agent.0,server,nowait +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 +-chardev spicevmc,id=charchannel1,name=vdagent +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 +-device usb-tablet,id=input0 +-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on +-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 +-device intel-hda,id=sound0,bus=pci.0,addr=0x5 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 +-chardev spicevmc,id=charredir0,name=usbredir +-device usb-redir,chardev=charredir0,id=redir0 +-chardev spicevmc,id=charredir1,name=usbredir +-device usb-redir,chardev=charredir1,id=redir1 +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 +-msg timestamp=on + +If this is not a bug, I'd be happy if you help me fix this problem. I am sorry if this is not the proper place to post such a problem. + +qemu-system-x86_64 --version +QEMU emulator version 2.1.3 (qemu-2.1.3-2.fc21), Copyright (c) 2003-2008 Fabrice Bellard + +qemu-kvm --version +QEMU emulator version 2.1.3 (qemu-2.1.3-2.fc21), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1434 b/results/classifier/gemma3:12b/hypervisor/1434 new file mode 100644 index 00000000..0c74440c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1434 @@ -0,0 +1,4 @@ + +Windows on ARM64 host support +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1446726 b/results/classifier/gemma3:12b/hypervisor/1446726 new file mode 100644 index 00000000..81159f3e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1446726 @@ -0,0 +1,35 @@ + +qemu stable 2.0 crashes during loadvm + +Qemu output: + +2015-03-06 01:06:54.255+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name instance-0000462a -S -machine pc-i440fx-trusty,accel=kvm,usb=off -cpu Westmere,+erms,+smep,+3dnowprefetch,+rdtscp,+rdrand,+tsc-deadline,+movbe,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 4096 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 7c3f225c-df2a-4014-997b-3200fcfff43d -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2014.1.2,serial=474aef35-d474-8001-e411-6108001017ac,uuid=7c3f225c-df2a-4014-997b-3200fcfff43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000462a.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,iops_rd=100,iops_wr=100 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/mapper/258c232d7056e0047,if=none,id=drive-virtio-disk1,format=raw,serial=dedb9d8d-e727-4d09-bf89-52e870125303,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/disk.config,if=none,id=drive-virtio-disk25,format=raw,cache=none,iops_rd=100,iops_wr=100 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk25,id=virtio-disk25 -chardev file,id=charserial0,path=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -k ja -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming fd:23 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 +char device redirected to /dev/pts/3 (label charserial1) +qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/memory.c:1403: memory_region_del_eventfd: Assertion `i != mr->ioeventfd_nb' failed. +2015-03-06 01:09:02.585+0000: shutting down + + +Libvirt log: +2015-03-05 11:29:48.434+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 00:13:33.077+0000: 8397: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping +2015-03-06 00:13:40.981+0000: 8397: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 00:14:27.206+0000: 8396: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 00:14:40.160+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 00:20:45.414+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 00:26:21.849+0000: 8396: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/25, skipping +2015-03-06 00:26:24.764+0000: 8396: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 00:28:09.425+0000: 8398: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 00:29:29.981+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 00:35:06.485+0000: 8398: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping +2015-03-06 00:35:09.645+0000: 8398: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 00:37:58.701+0000: 8397: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 00:59:12.925+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 01:04:57.990+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 01:05:18.031+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 01:05:37.954+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 01:06:13.213+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 01:06:29.870+0000: 8398: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping +2015-03-06 01:06:31.024+0000: 8398: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 01:06:57.274+0000: 8395: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 01:09:02.581+0000: 8392: error : qemuMonitorIORead:554 : Unable to read from monitor: Connection reset by peer \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1452904 b/results/classifier/gemma3:12b/hypervisor/1452904 new file mode 100644 index 00000000..6d46bab1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1452904 @@ -0,0 +1,209 @@ + +High CPU in idle Windows guest + +Hi, + +I'm running a freshly installed Windows 7 domU on an up-to-date Debian +jessie machine running Xen 4.4.1-9. When the Windows machine is idle, +I'm seeing upwards of 10% CPU usage from the qemu-system-i386 instance. +Other Linux and FreeBSD machines register negligable CPU usage (<0.5%). +The server is an HP Proliant DL360 G7. + +Data from perf attacthed to the process might give the best clues. + +Any information as to why this processes is comsuming so much CPU would +be much appreciated. + +Regards, +Terry. + +# uname -a +Linux xen 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux + +# lsb_release -a +No LSB modules are available. +Distributor ID: Debian +Description: Debian GNU/Linux 8.0 (jessie) +Release: 8.0 +Codename: jessie + +# qemu-system-i386 --version +QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-11), Copyright (c) 2003-2008 Fabrice Bellard + +# cat win7.cfg +name = 'win7' +vcpus = '1' +memory = '4096' +builder = 'hvm' +disk = [ '/vms/xen/domains/desk_win7/disk1.img,qcow2,hda,rw', + '/vms/xen/domains/desk_win7/disk2.img,qcow2,hdb,rw' ] +vfb = [ 'vnc=1,vnclisten="0.0.0.0",sdl=0' ] +vif = [ 'mac=00:16:3E:FB:FC:39,bridge=xenbr0' ] +serial = 'pty' +vnc = 1 +vnclisten = '0.0.0.0' +sdl = 0 +usbdevice = 'mouse' +audio = 1 +soundhw = 'sb16,es1370' +on_poweroff = 'destroy' +on_reboot = 'restart' +on_crash = 'restart' + +# /usr/bin/qemu-system-i386 -nodefaults -name desk_win7 -boot order=cda -usb -usbdevice mouse -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:fb:fc:39 -netdev type=tap,id=net0,ifname=vif12.0-emu,script=no,downscript=no -m 4088 -drive file=/vms/xen/domains/desk_win7/disk1.img,if=ide,index=0,media=disk,format=qcow2,cache=writeback -drive file=/vms/xen/domains/desk_win7/disk2.img,if=ide,index=1,media=disk,format=qcow2,cache=writeback -vnc 0.0.0.0:0,to=99 -display none -device cirrus-vga -global vga.vram_size_mb=8 + +# top +Tasks: 134 total, 1 running, 133 sleeping, 0 stopped, 0 zombie +%Cpu(s): 16.6 us, 5.5 sy, 0.0 ni, 0.0 id, 77.9 wa, 0.0 hi, 0.0 si, 0.0 st +KiB Mem: 354420 total, 348884 used, 5536 free, 184 buffers +KiB Swap: 17575932 total, 2642868 used, 14933064 free. 4132 cached Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +12297 root 20 0 6683864 192944 1140 S 20.6 54.4 2:25.51 qemu-syste+ + +# xen dmesg +(XEN) Xen version 4.4.1 (Debian 4.4.1-9) (<email address hidden>) (gcc (Debian 4.9.2-10) 4.9.2) debug=n Mon Apr 6 18:24:28 UTC 2015 +(XEN) Bootloader: GRUB 2.02~beta2-22 +(XEN) Command line: placeholder dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin radeon.modeset=0 iommu=no-intremap +(XEN) Video information: +(XEN) VGA is text mode 80x25, font 8x16 +(XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds +(XEN) EDID info not retrieved because no DDC retrieval method detected +(XEN) Disc information: +(XEN) Found 1 MBR signatures +(XEN) Found 1 EDD information structures +(XEN) Xen-e820 RAM map: +(XEN) 0000000000000000 - 000000000009f400 (usable) +(XEN) 000000000009f400 - 00000000000a0000 (reserved) +(XEN) 00000000000f0000 - 0000000000100000 (reserved) +(XEN) 0000000000100000 - 00000000cf62f000 (usable) +(XEN) 00000000cf62f000 - 00000000cf63c000 (ACPI data) +(XEN) 00000000cf63c000 - 00000000cf63d000 (usable) +(XEN) 00000000cf63d000 - 00000000d4000000 (reserved) +(XEN) 00000000fec00000 - 00000000fee10000 (reserved) +(XEN) 00000000ff800000 - 0000000100000000 (reserved) +(XEN) 0000000100000000 - 00000004affff000 (usable) +(XEN) ACPI: RSDP 000F4F00, 0024 (r2 HP ) +(XEN) ACPI: XSDT CF630140, 00B4 (r1 HP ProLiant 2 Ò 162E) +(XEN) ACPI: FACP CF630240, 00F4 (r3 HP ProLiant 2 Ò 162E) +(XEN) ACPI: DSDT CF630340, 20BD (r1 HP DSDT 1 INTL 20030228) +(XEN) ACPI: FACS CF62F100, 0040 +(XEN) ACPI: SPCR CF62F140, 0050 (r1 HP SPCRRBSU 1 Ò 162E) +(XEN) ACPI: MCFG CF62F1C0, 003C (r1 HP ProLiant 1 0) +(XEN) ACPI: HPET CF62F200, 0038 (r1 HP ProLiant 2 Ò 162E) +(XEN) ACPI: FFFF CF62F240, 0064 (r2 HP ProLiant 2 Ò 162E) +(XEN) ACPI: SPMI CF62F2C0, 0040 (r5 HP ProLiant 1 Ò 162E) +(XEN) ACPI: ERST CF62F300, 01D0 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: APIC CF62F500, 015E (r1 HP ProLiant 2 0) +(XEN) ACPI: SRAT CF62F680, 0570 (r1 HP Proliant 1 Ò 162E) +(XEN) ACPI: FFFF CF62FC00, 0176 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: BERT CF62FD80, 0030 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: HEST CF62FDC0, 00BC (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: DMAR CF62FE80, 0150 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: SSDT CF632400, 0125 (r3 HP CRSPCI0 2 HP 1) +(XEN) ACPI: SSDT CF632540, 01CF (r3 HP riser1a 2 INTL 20061109) +(XEN) ACPI: SSDT CF632740, 03BB (r1 HP pcc 1 INTL 20090625) +(XEN) ACPI: SSDT CF632B00, 0377 (r1 HP pmab 1 INTL 20090625) +(XEN) ACPI: SSDT CF632E80, 2094 (r1 INTEL PPM RCM 1 INTL 20061109) +(XEN) System RAM: 18421MB (18863928kB) +(XEN) Domain heap initialised +(XEN) Processor #0 6:12 APIC version 21 +(XEN) Processor #16 6:12 APIC version 21 +(XEN) Processor #4 6:12 APIC version 21 +(XEN) Processor #20 6:12 APIC version 21 +(XEN) Processor #2 6:12 APIC version 21 +(XEN) Processor #18 6:12 APIC version 21 +(XEN) Processor #1 6:12 APIC version 21 +(XEN) Processor #17 6:12 APIC version 21 +(XEN) Processor #5 6:12 APIC version 21 +(XEN) Processor #21 6:12 APIC version 21 +(XEN) Processor #3 6:12 APIC version 21 +(XEN) Processor #19 6:12 APIC version 21 +(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 +(XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec80000, GSI 24-47 +(XEN) Enabling APIC mode: Phys. Using 2 I/O APICs +(XEN) Failed to get Error Log Address Range. +(XEN) Using scheduler: SMP Credit Scheduler (credit) +(XEN) Detected 2533.485 MHz processor. +(XEN) Initing memory sharing. +(XEN) Intel VT-d iommu 0 supported page sizes: 4kB. +(XEN) Intel VT-d Snoop Control not enabled. +(XEN) Intel VT-d Dom0 DMA Passthrough not enabled. +(XEN) Intel VT-d Queued Invalidation enabled. +(XEN) Intel VT-d Interrupt Remapping not enabled. +(XEN) Intel VT-d Shared EPT tables not enabled. +(XEN) I/O virtualisation enabled +(XEN) - Dom0 mode: Relaxed +(XEN) Interrupt remapping disabled +(XEN) Enabled directed EOI with ioapic_ack_old on! +(XEN) ENABLING IO-APIC IRQs +(XEN) -> Using old ACK method +(XEN) Platform timer is 14.318MHz HPET +(XEN) Allocated console ring of 32 KiB. +(XEN) VMX: Supported advanced features: +(XEN) - APIC MMIO access virtualisation +(XEN) - APIC TPR shadow +(XEN) - Extended Page Tables (EPT) +(XEN) - Virtual-Processor Identifiers (VPID) +(XEN) - Virtual NMI +(XEN) - MSR direct-access bitmap +(XEN) - Unrestricted Guest +(XEN) HVM: ASIDs enabled. +(XEN) HVM: VMX enabled +(XEN) HVM: Hardware Assisted Paging (HAP) detected +(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB +(XEN) Brought up 12 CPUs +(XEN) *** LOADING DOMAIN 0 *** +(XEN) Xen kernel: 64-bit, lsb, compat32 +(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f18000 +(XEN) PHYSICAL MEMORY ARRANGEMENT: +(XEN) Dom0 alloc.: 000000049c000000->00000004a0000000 (110661 pages to be allocated) +(XEN) Init. ramdisk: 00000004aee45000->00000004afdff7d5 +(XEN) VIRTUAL MEMORY ARRANGEMENT: +(XEN) Loaded kernel: ffffffff81000000->ffffffff81f18000 +(XEN) Init. ramdisk: ffffffff81f18000->ffffffff82ed27d5 +(XEN) Phys-Mach map: ffffffff82ed3000->ffffffff82fd3000 +(XEN) Start info: ffffffff82fd3000->ffffffff82fd34b4 +(XEN) Page tables: ffffffff82fd4000->ffffffff82ff1000 +(XEN) Boot stack: ffffffff82ff1000->ffffffff82ff2000 +(XEN) TOTAL: ffffffff80000000->ffffffff83400000 +(XEN) ENTRY ADDRESS: ffffffff819021f0 +(XEN) Dom0 has maximum 1 VCPUs +(XEN) Scrubbing Free RAM: .................................................................................................................................................................................done. +(XEN) Initial low memory virq threshold set at 0x4000 pages. +(XEN) Std. Loglevel: Errors and warnings +(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) +(XEN) Xen is relinquishing VGA console. +(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) +(XEN) Freed 284kB init memory. + +# perf report +# To display the perf.data header info, please use --header/--header-only options. +# +# Samples: 6K of event 'cpu-clock' +# Event count (approx.): 1744250000 +# +# Overhead Command Shared Object Symbol +# ........ ............... ....................... .................................... +# + 8.69% qemu-system-i38 [kernel.kallsyms] [k] xen_hypercall_xen_version + 2.29% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acac8 + 2.01% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acad9 + 1.53% qemu-system-i38 qemu-system-i386 [.] 0x00000000000ac978 + 1.33% qemu-system-i38 qemu-system-i386 [.] 0x00000000000ac989 + 1.02% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acaa4 + 0.93% qemu-system-i38 libc-2.19.so [.] memset + 0.70% qemu-system-i38 qemu-system-i386 [.] 0x00000000000e2814 + 0.69% qemu-system-i38 qemu-system-i386 [.] 0x00000000000e37f4 + 0.67% qemu-system-i38 qemu-system-i386 [.] 0x00000000000aca40 + 0.66% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acadf + 0.60% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acad7 + 0.59% qemu-system-i38 [vdso] [.] __vdso_clock_gettime + 0.59% qemu-system-i38 qemu-system-i386 [.] 0x0000000000342b88 + 0.57% qemu-system-i38 [vdso] [.] __vdso_gettimeofday + 0.52% qemu-system-i38 [kernel.kallsyms] [k] pvclock_clocksource_read + 0.49% qemu-system-i38 qemu-system-i386 [.] 0x00000000000a9e45 + 0.46% qemu-system-i38 [kernel.kallsyms] [k] do_sys_poll + 0.37% qemu-system-i38 [kernel.kallsyms] [k] hrtimer_init + 0.36% qemu-system-i38 [kernel.kallsyms] [k] __fget + 0.34% qemu-system-i38 [kernel.kallsyms] [k] ktime_get_ts \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1455475 b/results/classifier/gemma3:12b/hypervisor/1455475 new file mode 100644 index 00000000..4f2962eb --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1455475 @@ -0,0 +1,67 @@ + +Block Commit: [100 %]error: failed to pivot job for disk vda + +Hi, + +i´ve a Problem with committing a snapshot. The problem was discussed on the libvirt mailing list earlier this year. + +https://www.redhat.com/archives/libvirt-users/2015-January/msg00029.html + + +Iam running gentoo and: + +Compiled against library: libvirt 1.2.14 +Using library: libvirt 1.2.14 +Using API: QEMU 1.2.14 +Running hypervisor: QEMU 2.3.0 + +I´am running a Windows Server 2012 R2 VM with the latest quest driver (0.1.96) and QEMU quest Agent 0.12.1 installed. + +The domain is started with following command line: + +/usr/bin/qemu-system-x86_64 -name $DOMAIN -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid c96ef576-dbfc-49aa-9dd0-068886c4ef0e -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/$DOMAIN.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/$DOMAIN.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:07:b4:0a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/f16x86_64.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 127.0.0.1:6 -k de -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +char device redirected to /dev/pts/2 (label charserial0) + + +I´ve created the snapshot with: + +virsh # snapshot-create-as --domain $DOMAIN snap1 --diskspec vda,file=/var/lib/libvirt/images/snap1.qcow2 --quiesce --disk-only --atomic --no-metadata +Domain snapshot snap1 created + +If i try to commit the snapshot i get this error: + +virsh # blockcommit $DOMAIN vda --active --verbose --pivot +error: internal error: unable to execute QEMU command 'block-commit': Device 'drive-virtio-disk0' is busy: block device is in use by block job: commit + + +virsh # blockjob $DOMAIN /var/lib/libvirt/images/snap1.qcow2 +Block Commit: [100 %] + +virsh # $DOMAIN var/lib/libvirt/images/snap1.qcow2 --abort + +virsh # blockjob $DOMAIN /var/lib/libvirt/images/snap1.qcow2 +No current block job for /var/lib/libvirt/images/snap1.qcow2 + + +I´ve test this with qemu 2.1 and the problem does`nt exist. + +/usr/bin/qemu-system-x86_64 -name $DOMAIN -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid 30c49f37-6e62-49f6-a9df-ad2fef1fa312 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/$DOMAIN.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/$DOMAIN.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/f16x86_64.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -k de -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + + + +Compiled against library: libvirt 1.2.11 +Using library: libvirt 1.2.11 +Using API: QEMU 1.2.11 +Running hypervisor: QEMU 2.1.2 + + +virsh # snapshot-create-as --domain windows.trohde-snapshot-test windows.trohde-snapshot-test_snap1 --diskspec vda,file=/var/lib/libvirt/images/windows.trohde-snapshot-test_snap1.qcow2 --quiesce --disk-only --atomic --no-metadata +Domain snapshot windows.trohde-snapshot-test_snap1 created + +virsh # blockcommit $DOMAIN vda --active --verbose --pivot +Block Commit: [100 %] +Successfully pivoted + +Cheers + +Tim \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1456819 b/results/classifier/gemma3:12b/hypervisor/1456819 new file mode 100644 index 00000000..c0e472cd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1456819 @@ -0,0 +1,101 @@ + +OVMF, Hyper-V, virtio, Win7 incompatibility + +Host kernel: v4.1-rc4 +QEMU: qemu.git tag v2.3.0 +OVMF: edk2.git-ovmf-x64-0-20150518.b1004.g54ae9c0.noarch +libvirt: 1.2.13.1-1.fc21.x86_64 +Guest: en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso + +If I attempt to use the above software versions to start a VM install, I hit one of two problems: + +(a) If I use a virtio NIC, the VM aborts with an error similar to: + +qemu-system-x86_64: Guest moved used index from 22 to 0 + +(b) If I use an emulated (e1000) NIC, the VM switches to a black screen when I should have the dancing windows boot animation logo + +Both of these are resolved by switching off ALL Hyper-V enlightenments as shown in the below XML. Enabling any one of them results in the above behavior. + +This problem is only seen with OVMF, removing the loader and nvram directives below allows all Hyper-V enlightenments to be enabled, with or without a virtio NIC. + +<domain type='kvm'> + <name>win7-ovmf-demo</name> + <uuid>a42b96e9-e95d-42c6-9f4a-0236f3d38d95</uuid> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>2</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/win7-ovmf-demo_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <pae/> + <hyperv> + <relaxed state='off'/> + <vapic state='off'/> + <spinlocks state='off'/> + </hyperv> + </features> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + <timer name='hypervclock' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/local/bin/qemu-system-x86_64</emulator> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/var/lib/libvirt/images/MSDN/en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso'/> + <target dev='hdb' bus='ide'/> + <readonly/> + <boot order='1'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <interface type='network'> + <mac address='52:54:00:9b:49:b9'/> + <source network='default'/> + <model type='e1000'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes'/> + <video> + <model type='vga' vram='16384' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='none'/> + </devices> +</domain> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1463463 b/results/classifier/gemma3:12b/hypervisor/1463463 new file mode 100644 index 00000000..9b7536fd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1463463 @@ -0,0 +1,13 @@ + +PCI devices on PCI to PCI bridges stopped being accessable from Xen with QEMU 2.3.0 + +The change set: + +commit 3996e85c1822e05c50250f8d2d1e57b6bea1229d +Author: Paul Durrant <email address hidden> +Date: Tue Jan 20 11:06:19 2015 +0000 + + Xen: Use the ioreq-server API when available +... + +Added calls to xen_map_pcidev() when available. However these call are only done at startup, not when the guest configures the PCI to PCI bridge. So Xen 4.5.0 (which has these) using a QEMU 2.3.0 or later can no longer access PCI devices that are not on a root bridge. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1473 b/results/classifier/gemma3:12b/hypervisor/1473 new file mode 100644 index 00000000..6ef3159f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1473 @@ -0,0 +1,2 @@ + +how to run qemu with sgx feature enabled diff --git a/results/classifier/gemma3:12b/hypervisor/1474 b/results/classifier/gemma3:12b/hypervisor/1474 new file mode 100644 index 00000000..018244a8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1474 @@ -0,0 +1,9 @@ + +qemu stuck at creating vm when enabling sgx feature +Description of problem: +After execute the command line, qemu stucked. + + + + +After the info in the png, qemu clear the screen and then nothing happend. diff --git a/results/classifier/gemma3:12b/hypervisor/148 b/results/classifier/gemma3:12b/hypervisor/148 new file mode 100644 index 00000000..8692bd2b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/148 @@ -0,0 +1,2 @@ + +Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM diff --git a/results/classifier/gemma3:12b/hypervisor/1480 b/results/classifier/gemma3:12b/hypervisor/1480 new file mode 100644 index 00000000..76bd5846 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1480 @@ -0,0 +1,2 @@ + +-cpu <whatever>,help should print the options available for that CPU type diff --git a/results/classifier/gemma3:12b/hypervisor/1484 b/results/classifier/gemma3:12b/hypervisor/1484 new file mode 100644 index 00000000..756c1013 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1484 @@ -0,0 +1,30 @@ + +cachy linux iso not booting in linux, host machine freezes +Description of problem: +- cachyos-gnome-linux-230121.iso + - boots native (core-i7 haswell) via ventoy-boot + - boots on windows (Win10 22H2 19045.2546) using + ``` + qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -bios E:\vstorage\win_m01_edk2-x8_64.fd -boot d -cdrom E:/transcend/cachyos-gnome-linux-230121.iso -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15,hostfwd=tcp::9551-:22 -device virtio-net,netdev=vmnic1 -device virtio-serial -chardev socket,path=C:/tmpq/Downloads/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -qmp "tcp:127.0.0.1:5955,server,nowait" + ``` + - does not boot on Linux. Infact it crashes the host, which is a much bigger problem + ``` + qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/m20_OVMF_VARS.fd" -cdrom /vol/15KJ_Images/transcend/cachyos-gnome-linux-230121.iso -device virtio-vga-gl -display "spice-app,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -device virtio-serial -chardev socket,path=/tmp/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait + ``` + when qemu windows pops up graphics inside the popped up virtviewer spice VM-window is garbled, seemingly of the grub2 bootscreen. + Initially, after window popup the mouse pointer can move for a few more seconds. + Then host machine GUI freezes + Then caps lock toggle/LED works for a while + Then host machine itself freezes. Even Ctrl-Alt-Fx to linux-console does not work. + Then forced to long-press power button and reboot + +Its one thing for the qemu to not be able to boot VM/iso, Its a whole different level bug to freeze the host-machine. +Fault inside VM should not affect outside. Plus, I think, I ran qemu-system-x86-64 as ordinary user and not as root. + +The self-built qemu-7.2.0 from handcrafted srpm has worked well with my other images. + +It may have something to do with virtio-vga-gl in linux but will need to test on next reboot to linux. +Steps to reproduce: +1. just run qemu command on linux +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1485010 b/results/classifier/gemma3:12b/hypervisor/1485010 new file mode 100644 index 00000000..33dc70bb --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1485010 @@ -0,0 +1,6 @@ + +qemu-guest-agent should support systemd in addition to pmutils + +Hello, + +Shouldn't the qemu-guest-agent also support systemd function in addition to the existing call to pm-suspend, shutdown, hwclock. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1497479 b/results/classifier/gemma3:12b/hypervisor/1497479 new file mode 100644 index 00000000..d50ff768 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1497479 @@ -0,0 +1,24 @@ + +memory corruption with migrate/savevm in TCG mode + +[ISSUE] + +QEMU releases 2.3.1 and lower are forgetting to flush TLBs before enabling the global dirty pages log and entering the final stage of saving the VM. + +[DESCRIPTION] + +The situation is the following: +1. TLB misses is the only way for page dirtying in the TCG mode. +2. If TLB is hit by a running VM during the execution of the `ram_save_iterate' by migration thread (e.g. if VM is mostly idling) then some pages are missing in the dirty log. +3. These pages are then not migrated during `ram_save_complete'. +4. This makes memory content in a saved VM state differ from the actual VM memory. +5. If the affected area includes some Kernel data structures such as trees or lists this can cause Kernel to Oops after loading the saved state. + +[SOLUTION] + +A proposed solution is to flush TLB when `log_global_start' is called. +Here is the patch: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1493049/+attachment/4459905/+files/tcg-commit-on-log-global-start.patch + +[LINKS] + +Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1493049 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/150 b/results/classifier/gemma3:12b/hypervisor/150 new file mode 100644 index 00000000..3d89d275 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/150 @@ -0,0 +1,2 @@ + +Illegal Instruction with HVF when encountering SSE instructions in the emulator diff --git a/results/classifier/gemma3:12b/hypervisor/1501 b/results/classifier/gemma3:12b/hypervisor/1501 new file mode 100644 index 00000000..7e0296a9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1501 @@ -0,0 +1,2 @@ + +IBM AIX 73 not supported under QEMU diff --git a/results/classifier/gemma3:12b/hypervisor/1509 b/results/classifier/gemma3:12b/hypervisor/1509 new file mode 100644 index 00000000..7f9896d2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1509 @@ -0,0 +1,162 @@ + +ppc64 tcg guests get incorrect Capacity Entitlement values from SMP spapr machine's RTAS - examples given from AIX guest OS +Description of problem: +Entitled Capacity of the guest OS is not equal to the number of vCPUs you configure with QEMU. + +It only gives you 1/4 entitlements to your configured capacity, and if you increase the number of processors, it converts the LPAR capacity to hundredths of a core, throttling guest performance. +Steps to reproduce: +Definition of terms from lparstat: +Entitled Capacity: The number of processing units this LPAR is entitled to receive. +Maximum Capacity: The maximum number of processing units this LPAR was defined to ever have. Entitled capacity can be increased up to this value. + +Some examples: + +1 QEMU vCPU: +Entitled Capacity: 0.25 +Maximum Capacity: 1.00 + +2 QEMU vCPUs (-smp cpus=2,sockets=1,cores=2,threads=1): +Entitled Capacity = 0.50 +Maximum Capacity: 0.02 + +3 QEMU CPUs (-smp cpus=3,sockets=1,cores=3,threads=1): +Entitled Capacity = 0.75 +Maximum Capacity: 0.03 + +4 QEMU CPUs (-smp cpus=4,sockets=1,cores=4,threads=1): +Entitled Capacity = 1.00 +Maximum Capacity: 0.04 + +I believe these Entitled and Maximum values are comming from the spapr machine's MaxEntCap, DesProcs and MaxPlatProcs settings which get affected by -smp passed to QEMU. +Additional information: +Details: + +1 QEMU vCPU: + ``` +kens@aix-ppc64$ lparstat -i | head -20 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +Partition Number : 0 +Type : Shared +Mode : Capped +Entitled Capacity : 0.25 +Partition Group-ID : 1 +Shared Pool ID : 1 +Online Virtual CPUs : 1 +Maximum Virtual CPUs : 1 +Minimum Virtual CPUs : 1 +Online Memory : 8192 MB +Maximum Memory : 8192 MB +Minimum Memory : 8192 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.01 +Maximum Capacity : 1.00 +Capacity Increment : 1.00 +Maximum Physical CPUs in system : 1 +Active Physical CPUs in system : 1 + ``` +2 QEMU vCPUs: + ``` +kens@aix-ppc64$ lparstat -i | head -20 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +Partition Number : 0 +Type : Shared +Mode : Capped +Entitled Capacity : 0.50 +Partition Group-ID : 1 +Shared Pool ID : 1 +Online Virtual CPUs : 2 +Maximum Virtual CPUs : 2 +Minimum Virtual CPUs : 2 +Online Memory : 8192 MB +Maximum Memory : 8192 MB +Minimum Memory : 8192 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.02 +Maximum Capacity : 0.02 +Capacity Increment : 1.00 +Maximum Physical CPUs in system : 2 +Active Physical CPUs in system : 2 + ``` +3 QEMU vCPUs: + ``` +kens@aix-ppc64$ lparstat -i | head -20 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +Partition Number : 0 +Type : Shared +Mode : Capped +Entitled Capacity : 0.75 +Partition Group-ID : 1 +Shared Pool ID : 1 +Online Virtual CPUs : 3 +Maximum Virtual CPUs : 3 +Minimum Virtual CPUs : 3 +Online Memory : 8192 MB +Maximum Memory : 8192 MB +Minimum Memory : 8192 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.03 +Maximum Capacity : 0.03 +Capacity Increment : 1.00 +Maximum Physical CPUs in system : 3 +Active Physical CPUs in system : 3 + ``` +4 QEMU vCPUs: + ``` +kens@aix-ppc64$ lparstat -i | head -2 +lparstat -i | head -2 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +kens@aix-ppc64$ lparstat -i | head -20 +lparstat -i | head -20 +Node Name : aix-ppc64 +Partition Name : IBM AIX - IBM POWER9 +Partition Number : 0 +Type : Shared +Mode : Capped +Entitled Capacity : 1.00 +Partition Group-ID : 1 +Shared Pool ID : 1 +Online Virtual CPUs : 4 +Maximum Virtual CPUs : 4 +Minimum Virtual CPUs : 4 +Online Memory : 8192 MB +Maximum Memory : 8192 MB +Minimum Memory : 8192 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.04 +Maximum Capacity : 0.04 +Capacity Increment : 1.00 +Maximum Physical CPUs in system : 4 +Active Physical CPUs in system : 4 + ``` +So it seems to me like the OS assumes the following from the spapr machine settings: +Entitled Capacity = cpus / 4 (OS is assuming smt=4 threads maybe, see below) +Maximim Capacity = cpus / 100 (OS is assuming hundredths of a core, even though the Capacity Increment is 1.00, see below)) + +On a real Power system (POWER8, smt=8), it looks like this: + ``` +kens@aix72$ lparstat -i | head -20 +Node Name : aix72 +Partition Name : n1 +Partition Number : 1 +Type : Shared-SMT-4 +Mode : Uncapped +Entitled Capacity : 6.00 +Partition Group-ID : 32784 +Shared Pool ID : 0 +Online Virtual CPUs : 12 +Maximum Virtual CPUs : 28 +Minimum Virtual CPUs : 1 +Online Memory : 131072 MB +Maximum Memory : 196608 MB +Minimum Memory : 1024 MB +Variable Capacity Weight : 128 +Minimum Capacity : 0.50 +Maximum Capacity : 14.00 +Capacity Increment : 0.01 +Maximum Physical CPUs in system : 80 +Active Physical CPUs in system : 80 + ``` diff --git a/results/classifier/gemma3:12b/hypervisor/1516446 b/results/classifier/gemma3:12b/hypervisor/1516446 new file mode 100644 index 00000000..42a72381 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1516446 @@ -0,0 +1,531 @@ + +Migration always causes guest freeze in one direction. + +Hello, + +I have three debian jessie machines standard installations except for homebuild qemu-2.4.0 package using the source package from testing. I had the same problem with the standard debian jessie qemu 2.1 too. + +I have host A, B and C. + +Migrations work between all combinations of these except A -> B. B -> A works. + +I use libvirt but as per your written request I have run qemu directly and verified the same problem. + +Host A: +qemu-system-x86_64 --enable-kvm -name ashole -cpu kvm64 -m 1024 -drive file=/mnt/synctest/ashole.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none -vnc 0.0.0.0:600 -k sv -vga std -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 + +Host B: +qemu-system-x86_64 --enable-kvm -name ashole -cpu kvm64 -m 1024 -drive file=/mnt/synctest/ashole.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none -vnc 0.0.0.0:600 -k sv -vga std -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -incoming tcp:0:4444 + +Then in qemu monitor I run migrate -d tcp:B:4444 and the guest freeze. + +I have tried with these guest os:es, freebsd 9.1, debian wheezy and debian jessie (Standard 3.16 kernel and backported 4.2 kernel), same problem with all of them. when running the migration through libvirt virt-manager says the guest is using 100% cpu. + +I had a similar problem (https://bugzilla.kernel.org/show_bug.cgi?id=61971) 2 years ago which was solved in kernel 3.13 if I remember correctly. + +Best Regards +Magnus + +CPU info: +Host A +processor : 0 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 0 +cpu cores : 4 +apicid : 16 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +processor : 1 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 1 +cpu cores : 4 +apicid : 17 +initial apicid : 1 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +processor : 2 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1700.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 2 +cpu cores : 4 +apicid : 18 +initial apicid : 2 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +processor : 3 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 3 +cpu cores : 4 +apicid : 19 +initial apicid : 3 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +processor : 4 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 4 +cpu cores : 4 +apicid : 20 +initial apicid : 4 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +processor : 5 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 5 +cpu cores : 4 +apicid : 21 +initial apicid : 5 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +processor : 6 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 6 +cpu cores : 4 +apicid : 22 +initial apicid : 6 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +processor : 7 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 7 +cpu cores : 4 +apicid : 23 +initial apicid : 7 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +Host B: +processor : 0 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 0 +cpu cores : 6 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 6 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 1 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 1 +cpu cores : 6 +apicid : 1 +initial apicid : 1 +fpu : yes +fpu_exception : yes +cpuid level : 6 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 2 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 2 +cpu cores : 6 +apicid : 2 +initial apicid : 2 +fpu : yes +fpu_exception : yes +cpuid level : 6 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 3 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 3 +cpu cores : 6 +apicid : 3 +initial apicid : 3 +fpu : yes +fpu_exception : yes +cpuid level : 6 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 4 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 4 +cpu cores : 6 +apicid : 4 +initial apicid : 4 +fpu : yes +fpu_exception : yes +cpuid level : 6 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 5 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 5 +cpu cores : 6 +apicid : 5 +initial apicid : 5 +fpu : yes +fpu_exception : yes +cpuid level : 6 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +Host C: +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz +stepping : 9 +microcode : 0x12 +cpu MHz : 1607.156 +cache size : 6144 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt +bugs : +bogomips : 6186.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 1 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz +stepping : 9 +microcode : 0x12 +cpu MHz : 1730.066 +cache size : 6144 KB +physical id : 0 +siblings : 4 +core id : 1 +cpu cores : 4 +apicid : 2 +initial apicid : 2 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt +bugs : +bogomips : 6186.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 2 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz +stepping : 9 +microcode : 0x12 +cpu MHz : 1654.382 +cache size : 6144 KB +physical id : 0 +siblings : 4 +core id : 2 +cpu cores : 4 +apicid : 4 +initial apicid : 4 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt +bugs : +bogomips : 6186.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 3 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz +stepping : 9 +microcode : 0x12 +cpu MHz : 1610.304 +cache size : 6144 KB +physical id : 0 +siblings : 4 +core id : 3 +cpu cores : 4 +apicid : 6 +initial apicid : 6 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt +bugs : +bogomips : 6186.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1517 b/results/classifier/gemma3:12b/hypervisor/1517 new file mode 100644 index 00000000..69f7595e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1517 @@ -0,0 +1,2 @@ + +TCG doesn't support requested feature: CPUID.80000001H:EDX.syscall [bit 11]/TCG doesn't support requested feature: CPUID.80000001H:EDX.lm [bit 29] diff --git a/results/classifier/gemma3:12b/hypervisor/1527322 b/results/classifier/gemma3:12b/hypervisor/1527322 new file mode 100644 index 00000000..016d444b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1527322 @@ -0,0 +1,21 @@ + +segfault in thread-pool.c:246:5: + +Building qemu-2.5.0 with -fsanitize=undefined shows, e.g.: + +markus@x4 linux % qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user -fsdev local,security_model=none,id=root,path=/ -device virtio-9p-pci,id=root,fsdev +=root,mount_tag=/dev/root -m 512 -smp 2 -kernel /usr/src/linux/arch/x86/boot/bzImage -nographic -append "init=/bin/zsh root=/dev/root console=ttyS0 kgdboc=ttyS0 rootflags=rw, +trans=virtio rootfstype=9p ip=dhcp earlyprintk=ttyS0" +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/exec.c:307:5: runtime error: variable length array bound evaluates to non-positive value 0 +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/hw/i386/kvm/apic.c:37:47: runtime error: left shift of 15 by 28 places cannot be represented in type 'int' +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/include/qemu/rcu.h:85:21: runtime error: member access within null pointer of type 'struct rcu_reader_data' +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/include/qemu/rcu.h:101:5: runtime error: member access within null pointer of type 'struct rcu_reader_data' +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/include/qemu/rcu.h:102:8: runtime error: member access within null pointer of type 'struct rcu_reader_data' +... +ALSA device list: + No soundcards found. +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/thread-pool.c:246:5: runtime error: member access within null pointer of type 'struct ThreadPool' +[1] 9295 segmentation fault qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user + +As you can see it segfaults when build with upcoming gcc-6, that is more aggressive when it comes to undefined behavior. +The compiler just assumes that "this" can never be NULL and optimizes accordingly. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1529 b/results/classifier/gemma3:12b/hypervisor/1529 new file mode 100644 index 00000000..9ee1563d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1529 @@ -0,0 +1,2 @@ + +Documentation refers to Windows Hypervisor Platform as wphx instead of whpx diff --git a/results/classifier/gemma3:12b/hypervisor/1529226 b/results/classifier/gemma3:12b/hypervisor/1529226 new file mode 100644 index 00000000..aec8a1a9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1529226 @@ -0,0 +1,12 @@ + +qemu-i386-user on 32-bit Linux: uncaught target signal 11 + +Even though the command I'm trying to run (a wrapper script for qemu-i386-user running rustc, the rust compiler) produces the expected compiled output, the build process is interrupted: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +i686-unknown-linux-gnu/stage0/bin/rustc: line 1: 7474 Segmentation fault /usr/local/bin/qemu-i386 -cpu qemu32 /home/petevine/stage0/rustc.bin -C target-cpu=pentium2 -L /home/petevine/unpacked/rust-master/i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/ "$@" +make: *** [i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.rustc_back] Error 139 + +The stamp file is not being created so this could be about forking bash after finishing the wrapper script. + +Qemu was compiled from the latest git source. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1531632 b/results/classifier/gemma3:12b/hypervisor/1531632 new file mode 100644 index 00000000..87a9a81b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1531632 @@ -0,0 +1,95 @@ + +Can't compile qemu because of errors in the Xen code + +I'm using Arch Linux, with all needed libs packages installed via ABS (compiled from source). +I tried to clone the master repository, the v2.5.0 and the stable-2.4.0, all I had the same problems: + +First I have to disable -Werror, because it claims about some uninitialized variables. + +Trying to compile the code, it stops when compiling the xen code (hw/block/xendisk.o), complaining that ioservid_t is declared twice, first as 16bit and then as 32bit. + +Output of make: + + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 +[leo@AlphaArch build]$ make + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 +[leo@AlphaArch build]$ make + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1533 b/results/classifier/gemma3:12b/hypervisor/1533 new file mode 100644 index 00000000..3fa52690 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1533 @@ -0,0 +1,2 @@ + +qemu-i386 should not enable feature LM with named CPU models. diff --git a/results/classifier/gemma3:12b/hypervisor/1534 b/results/classifier/gemma3:12b/hypervisor/1534 new file mode 100644 index 00000000..7bd9c68a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1534 @@ -0,0 +1,2 @@ + +usermode emulation warns about features that are system-only (x2apic, tsc-deadline, pcid, invpcid) diff --git a/results/classifier/gemma3:12b/hypervisor/1535 b/results/classifier/gemma3:12b/hypervisor/1535 new file mode 100644 index 00000000..39e379e3 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1535 @@ -0,0 +1,92 @@ + +spapr set host serial number visible to AIX from -M pseries,host-serial and not -uuid +Description of problem: +-M pseries,host-serial populates "/host-serial" which is not used in AIX and populates "/system-id" with UUID instead of serial number. Patch to write host-serial passed to -M as "/system-id" prefixed with IBM,06 visible from `uname -u` and `nmon`. +Steps to reproduce: +1. Set -uuid and -M pseries,host-serial +2. Execute `uname -u` and `nmon` in guest +Additional information: +Patch: +``` +diff -ru a/hw/ppc/spapr.c b/hw/ppc/spapr.c +--- a/hw/ppc/spapr.c 2023-03-06 13:59:32.942881783 -0500 ++++ b/hw/ppc/spapr.c 2023-03-06 21:37:32.504570961 -0500 +@@ -1163,7 +1163,10 @@ + } + + if (spapr->host_serial) { +- _FDT(fdt_setprop_string(fdt, 0, "host-serial", spapr->host_serial)); ++ /* plus 1 byte for null character */ ++ char result[sizeof("IBM,06") + sizeof(spapr->host_serial) + 1]; ++ snprintf(result, sizeof(result), "%s%s", "IBM,06", spapr->host_serial); ++ _FDT(fdt_setprop_string(fdt, 0, "system-id", result)); + } else if (smc->broken_host_serial_model && kvmppc_get_host_serial(&buf)) { + _FDT(fdt_setprop_string(fdt, 0, "host-serial", buf)); + g_free(buf); +``` + +Before patch: +``` +$ uname -u +2d861abf-5cb7-434a-86d5-65167d85e5af + +$ nmon +┌──────────────────────────────────────────────────────────────────────────────────┐ +│ ------------------------------ │ +│ N N M M OOOO N N For online help type: h │ +│ NN N MM MM O O NN N For command line option help: │ +│ N N N M MM M O O N N N quick-hint nmon -? │ +│ N N N M M O O N N N full-details nmon -h │ +│ N NN M M O O N NN To start nmon the same way every time? │ +│ N N M M OOOO N N set NMON ksh variable, for example: │ +│ ------------------------------ export NMON=cmt │ +│ TOPAS_NMON │ +│ 8 - CPUs currently │ +│ 8 - CPUs configured │ +│ 1000 - MHz CPU clock rate (press 'r' for current MHz) │ +│ PowerPC_POWER10 - Processor │ +│ 64 bit - Hardware │ +│ 64 bit - Kernel │ +│ 0,IBM AIX - IBM POWER10 - Logical Partition │ +│ 7.2.5.200 TL05 - AIX Kernel Version │ +│ aix-ppc64 - Hostname │ +│ aix-ppc64 - Node/WPAR Name │ +│ bf-5cb7 - Serial Number │ +│ IBM,9080-HEX - Machine Type │ +│ │ +│ │ +└────────────────────────────────────────────────────────────────────────────────── +``` +After patch: +``` +$ uname -u +IBM,0678AB123 + +$ nmon +┌──────────────────────────────────────────────────────────────────────────────────┐ +│ ------------------------------ │ +│ N N M M OOOO N N For online help type: h │ +│ NN N MM MM O O NN N For command line option help: │ +│ N N N M MM M O O N N N quick-hint nmon -? │ +│ N N N M M O O N N N full-details nmon -h │ +│ N NN M M O O N NN To start nmon the same way every time? │ +│ N N M M OOOO N N set NMON ksh variable, for example: │ +│ ------------------------------ export NMON=cmt │ +│ TOPAS_NMON │ +│ 8 - CPUs currently │ +│ 8 - CPUs configured │ +│ 1000 - MHz CPU clock rate (press 'r' for current MHz) │ +│ PowerPC_POWER10 - Processor │ +│ 64 bit - Hardware │ +│ 64 bit - Kernel │ +│ 0,IBM AIX - IBM POWER10 - Logical Partition │ +│ 7.2.5.200 TL05 - AIX Kernel Version │ +│ aix-ppc64 - Hostname │ +│ aix-ppc64 - Node/WPAR Name │ +│ 78AB123 - Serial Number │ +│ IBM,9080-HEX - Machine Type │ +│ │ +│ │ +└────────────────────────────────────────────────────────────────────────────────── +``` +Note first 6 characters of serial number are cropped by nmon ("IBM,06") diff --git a/results/classifier/gemma3:12b/hypervisor/155 b/results/classifier/gemma3:12b/hypervisor/155 new file mode 100644 index 00000000..bd929a45 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/155 @@ -0,0 +1,2 @@ + +MMX emulation is missing on HVF Acceleration diff --git a/results/classifier/gemma3:12b/hypervisor/1553760 b/results/classifier/gemma3:12b/hypervisor/1553760 new file mode 100644 index 00000000..d1880276 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1553760 @@ -0,0 +1,6 @@ + +NUMA node binding are not supported by this QEMU + +I read https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1417937/, but I don't understand why it was only fixed on Ubunto. +I'm running on Debian 8, openstack kilo, and trying to launch a VM with numa pinning. +Is it not possible to build qemu with CONFIG_NUMA enabled for Debian where libnuma is present? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1558 b/results/classifier/gemma3:12b/hypervisor/1558 new file mode 100644 index 00000000..1c1448dd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1558 @@ -0,0 +1,22 @@ + +Bug checklist for AEHD +Description of problem: +There was a discussion on qemu-devel about addition of a new hypervisor, which is essentially a rewrite of linux/kvm, but for windows +- 202303002 Haito Shan [PATCH 0/6] Adding the Android Emulator hypervisor driver accelerator + https://lore.kernel.org/qemu-devel/CAGD3tSzW1QoAsn+uGjoAkBegLt1iZ=9YWDFcvqbcHMr0S_5kVw@mail.gmail.com/ + +If the new hypervisor AEHD does not support these, then each of the below may automatically qualify as a feature catchup bug +1) Nested Virtualization +2) virtio-GPU/virgl/OpenGL/venus +3) Vulkan passthrough +4) Xen emulation on KVM ( a feature also currently under development) + 20230302 [phase1-qemu-8.0](https://lore.kernel.org/qemu-devel/20230302123029.153265-1-pbonzini@redhat.com/) [PULL 00/62] i386, misc changes for QEMU 8.0 soft freeze + 20230307 [phase2-qemu-8.0](https://lore.kernel.org/qemu-devel/20230307171750.2293175-1-dwmw2@infradead.org/) [PATCH v2 00/27] Enable PV backends with Xen/KVM emulation +5) Migration +6) others?? + +perhaps also document if known for certain that there is no intention to catchup to a particular feature. +Steps to reproduce: +NA +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1568107 b/results/classifier/gemma3:12b/hypervisor/1568107 new file mode 100644 index 00000000..920003b0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1568107 @@ -0,0 +1,10 @@ + +x86_64 linux-user: setup_rt_frame: not implemented + +Trying to run this binary (https://github.com/ethcore/parity/releases/download/v1.0.1/parity_linux_1.0.1-0_amd64.deb) under qemu-x86_64 on ARM, ends like this: + +$ qemu-x86_64 parity --pruning fast + +setup_rt_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1571 b/results/classifier/gemma3:12b/hypervisor/1571 new file mode 100644 index 00000000..edffa5c3 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1571 @@ -0,0 +1,13 @@ + +accel/hvf: Instance size not properly declared +Description of problem: +In [`include/sysemu/hvf.h`](https://gitlab.com/qemu-project/qemu/-/blob/master/include/sysemu/hvf.h#L36), `HVFState` is declared to have the QOM type `TYPE_HVF_ACCEL`; +However, when the type is registered, proper `instance_size` for it was [not declared](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L351). + +As a result, a bad workaround was introduced. That is, when [`hvf_accel_init`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L329) is called from [`accel_init_machine`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/accel-softmmu.c#L33), an new instance of `HVFState` is allocated while we should have used the pre-allocated instance in `ms->accelerator` similar to [what KVM does](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/kvm/kvm-all.c#L2381) (the code didn't do so since the allocated ([using `object_new_with_class`](https://gitlab.com/qemu-project/qemu/-/blob/master/softmmu/vl.c#L2218)) instance didn't allocate enough memory for `HVFState`). + +Eventhough the code wouldn't crash nor have any serious implication, this would leak an `AccelState` and attempts to manually manage accelerators would cause a buffer-overflow. +Steps to reproduce: +1. Run a HVF-accelerated VM +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1574346 b/results/classifier/gemma3:12b/hypervisor/1574346 new file mode 100644 index 00000000..01f55e51 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1574346 @@ -0,0 +1,13 @@ + +TCG: mov to segment register is incorrectly emulated for AMD CPUs + +In TCG mode, the effect of: + +xorl %eax, %eax +movl %eax, %gs + +is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. + +This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. + +To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1578 b/results/classifier/gemma3:12b/hypervisor/1578 new file mode 100644 index 00000000..2e21adc6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1578 @@ -0,0 +1,4 @@ + +Send all the SVQ control commands in parallel instead of serialized +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1583775 b/results/classifier/gemma3:12b/hypervisor/1583775 new file mode 100644 index 00000000..7e74cc9d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1583775 @@ -0,0 +1,8 @@ + +Feature Request: qemu 2.6.0 + +Qemu 2.6.0 just got released, and according to changelogs it has quite some enhancements... + +would it be possible to have someone who has a qemu ppa on launchpad to migrate this into his ppa? + +thanks in advance \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1585432 b/results/classifier/gemma3:12b/hypervisor/1585432 new file mode 100644 index 00000000..85742052 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1585432 @@ -0,0 +1,11 @@ + +magnum coe-service-list returns error + +magnum running on centos7, + +I didn't create any services on k8s cluster, + +but I got the result as follows: + +[root@localhost ~(keystone_admin)]# magnum coe-service-list --bay k8sbay3 +ERROR: Field `ports[0][node_port]' cannot be None (HTTP 500) (Request-ID: req-c66b68dd-5437-47fa-a389-7cb56a262fa5) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1585433 b/results/classifier/gemma3:12b/hypervisor/1585433 new file mode 100644 index 00000000..9ec7006d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1585433 @@ -0,0 +1,11 @@ + +if docker-volume-size of baymodel lessthan 3, bay cann't create + +magnum is running on centos7, + + +magnum baymodel-create --name k8sbaymodel5 --image-id fedora-23-atomic-20160405 --keypair-id testkey --external-network-id public --dns-nameserver 8.8.8.8 --flavor-id m1.small --coe kubernetes --docker-volume-size 5 + +magnum bay-create --name k8sbay5 --baymodel k8sbaymodel5 --node-count 1 + +Execute the above command can get a completed bay,but when docker-volume-size is 1 or 2,the status of bay is FAILED. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1585533 b/results/classifier/gemma3:12b/hypervisor/1585533 new file mode 100644 index 00000000..d82dd67a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1585533 @@ -0,0 +1,15 @@ + +cache-miss-rate / Invalid JSON + +Hi, + +We have VMs which were started with an older version than qemu 2.1 which added "cache-miss-rate" property for XBZRLECacheStats. While trying to migrate the VM to a new host which is running a higher version (2.3) of Qemu we got an exception: + +virJSONValueFromString:1642 : internal error: cannot parse json {"return": {"expected-downtime": 1, "xbzrle-cache": {"bytes": 0, "cache-size": 67108864, "cache-miss-rate": -nan, "pages": 0, "overflow": 0, "cache-miss": 8933}, "status": "active", "disk": {"total": 429496729600, "dirty-sync-count": 0, "remaining": 193896382464, "mbps": 0, "transferred": 235600347136, "duplicate": 0, "dirty-pages-rate": 0, "skipped": 0, "normal-bytes": 0, "normal": 0}, "setup-time": 13, "total-time": 1543124, "ram": {"total": 8599183360, "dirty-sync-count": 4, "remaining": 30695424, "mbps": 830.636997, "transferred": 3100448901, "duplicate": 1358341, "dirty-pages-rate": 7, "skipped": 0, "normal-bytes": 3082199040, "normal": 752490}}, "id": "libvirt-186200"}: lexical error: malformed number, a digit is required after the minus sign. + 67108864, "cache-miss-rate": -nan, "pages": 0, "overflow": 0 + (right here) ------^ + +virNetClientStreamRaiseError:191 : stream aborted at client request + + +Would it be possible to improve the JSON parser to skip the key if the value is incorrect instead of throwing an exception? Then hopefully qemu 2.3 or higher is able to handle the data without this property, falling back to its default. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1587 b/results/classifier/gemma3:12b/hypervisor/1587 new file mode 100644 index 00000000..7f87ba46 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1587 @@ -0,0 +1,26 @@ + +Invalid memory access allowed (possibly due to TLB bypassing PMP after mret) +Description of problem: +A load instruction that should be blocked by PMP due to MPRV changing the effective privilege mode to U is allowed. The sequence that I observed was: + + +1. Be in machine mode. +2. Set MPP to U (0). +3. Set MPRV to 1. +4. Enter an ISR, setting MPP to M (3). +5. Load from address xxxx (populating the QEMU TLB). +6. Execute mret, setting MPP back to U (0). +7. Load from address xxxx, which should fail but succeeds without any TLB fill. +Steps to reproduce: +``` +git clone https://github.com/dreiss/qemu_pmp_repro +cd qemu_pmp_repro +./build_and_run.sh +``` +The `build_and_run.sh` script expects `riscv-none-elf-gcc` and `qemu-system-riscv64` on PATH. It will also attempt to run the reproducer with `spike`, the reference RISC-V emulator, which succeeds. +Additional information: +Adding a call to `tlb_flush` to `helper_mret` causes this test to pass in QEMU, but I don't know if that's a valid fix. + +Output from `build_and_run.sh`: + +[output.txt](/uploads/108547bcb160a8f0bfffe72ea77b215f/output.txt) diff --git a/results/classifier/gemma3:12b/hypervisor/1588 b/results/classifier/gemma3:12b/hypervisor/1588 new file mode 100644 index 00000000..e5409935 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1588 @@ -0,0 +1,170 @@ + +virsh backup-begin crashes guest - qcow2_get_specific_info: Assertion `false' failed. +Description of problem: +I run a daily backup job of around 350 guests, scattered on different host machines. + +Each day around 1-2 guests crashes on virsh backup-begin with the following error in /var/log/libvirt/qemu/$GUEST.log: + +```qemu-system-x86_64: ../../block/qcow2.c:5175: qcow2_get_specific_info: Assertion `false' failed.``` (https://github.com/qemu/qemu/blob/0c8022876f2183f93e23a7314862140c94ee62e7/block/qcow2.c) + +Different guests every day, no patterns what I can see. + +I'm using a top and a base image with incremental backups, qcow2 compat 1.1, output of qemu-img info of the base and top image; + +``` +qemu-img info base.qcow2 +image: base.qcow2 +file format: qcow2 +virtual size: 5 GiB (5368709120 bytes) +disk size: 1.9 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + corrupt: false + extended l2: false + +qemu-img info -U top.qcow2 +image: top.qcow2 +file format: qcow2 +virtual size: 60 GiB (64424509440 bytes) +disk size: 1.36 GiB +cluster_size: 65536 +backing file: base.qcow2 +backing file format: qcow2 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + bitmaps: + [0]: + flags: + [0]: in-use + [1]: auto + name: 1680670811 + granularity: 65536 + refcount bits: 16 + corrupt: false + extended l2: false +``` + +I know I'm not be using the latest qemu and that this is difficult to reproduce. This bug happens in production and upgrading qemu would be a huge task, given that I would have to upgrade the entire production. Nevertheless I of course would be willing to do it if deemed necessary but at this point I'm just looking for directions on how to pin point this bug. + +A "guest-1" grepped version of libvirt debug logs during the seconds this happened: + +``` +2023-04-08 20:37:20.453+0000: 431153: debug : virDomainLookupByName:413 : conn=0x7fbff000ca30, name=guest-1 +2023-04-08 20:37:20.453+0000: 431153: debug : virDomainDispose:348 : release domain 0x7fc068021c60 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.454+0000: 431155: debug : virDomainGetState:2493 : dom=0x7fc068024330, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), state=0x7fc08c052cf0, reason=0x7fc08c052cf4, flags=0x0 +2023-04-08 20:37:20.454+0000: 431155: debug : virDomainDispose:348 : release domain 0x7fc068024330 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.483+0000: 431152: debug : virDomainLookupByName:413 : conn=0x7fc070014e90, name=guest-1 +2023-04-08 20:37:20.483+0000: 431152: debug : virDomainDispose:348 : release domain 0x7fc0500075f0 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.483+0000: 431148: debug : virDomainListAllCheckpoints:292 : dom=0x7fc0ac002380, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), checkpoints=0x7fc0b79018a8, flags=0x0 +2023-04-08 20:37:20.483+0000: 431148: debug : virDomainDispose:348 : release domain 0x7fc0ac002380 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.484+0000: 431151: debug : virDomainDispose:348 : release domain 0x7fc0b0006950 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.516+0000: 431150: debug : virDomainLookupByName:413 : conn=0x7fc0a80027a0, name=guest-1 +2023-04-08 20:37:20.516+0000: 431150: debug : virDomainDispose:348 : release domain 0x7fc08c007c60 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.516+0000: 431152: debug : virDomainGetState:2493 : dom=0x7fc068021e90, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), state=0x7fc0a47c64d0, reason=0x7fc0a47c64d4, flags=0x0 +2023-04-08 20:37:20.516+0000: 431152: debug : virDomainDispose:348 : release domain 0x7fc068021e90 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.544+0000: 431156: debug : virDomainLookupByName:413 : conn=0x7fc0a80025a0, name=guest-1 +2023-04-08 20:37:20.544+0000: 431156: debug : virDomainDispose:348 : release domain 0x7fc068029d00 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.544+0000: 431149: debug : virDomainSuspend:623 : dom=0x7fc050007500, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f) +2023-04-08 20:37:20.544+0000: 431149: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=suspend agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=none) +2023-04-08 20:37:20.544+0000: 431149: debug : qemuDomainObjBeginJobInternal:883 : Started job: suspend (async=none vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.544+0000: 431149: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.580+0000: 1882669: debug : qemuProcessHandleStop:660 : Transitioned guest guest-1 to paused state, reason user, event detail 0 +2023-04-08 20:37:20.580+0000: 1882669: debug : virLockManagerLogParams:90 : key=name type=string value=guest-1 +2023-04-08 20:37:20.580+0000: 1882669: debug : virDomainLockManagerAddImage:90 : Add disk /home/vm/domains/guest-1/disk.qcow2 +2023-04-08 20:37:20.580+0000: 1882669: debug : virLockManagerAddResource:325 : lock=0x7fbf8801fdc0 type=0 name=/home/vm/domains/guest-1/disk.qcow2 nparams=0 params=(nil) flags=0x0 +2023-04-08 20:37:20.581+0000: 431149: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.581+0000: 431149: debug : virLockManagerLogParams:90 : key=name type=string value=guest-1 +2023-04-08 20:37:20.581+0000: 431149: debug : virDomainLockManagerAddImage:90 : Add disk /home/vm/domains/guest-1/disk.qcow2 +2023-04-08 20:37:20.581+0000: 431149: debug : virLockManagerAddResource:325 : lock=0x7fc0a8968e60 type=0 name=/home/vm/domains/guest-1/disk.qcow2 nparams=0 params=(nil) flags=0x0 +2023-04-08 20:37:20.582+0000: 431149: debug : qemuDomainObjEndJob:1135 : Stopping job: suspend (async=none vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.582+0000: 431149: debug : virDomainDispose:348 : release domain 0x7fc050007500 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.608+0000: 431148: debug : virDomainLookupByName:413 : conn=0x7fbff000cc30, name=guest-1 +2023-04-08 20:37:20.608+0000: 431148: debug : virDomainDispose:348 : release domain 0x7fc07001e330 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.608+0000: 431151: debug : virDomainGetState:2493 : dom=0x7fc050007550, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), state=0x7fc0a003d640, reason=0x7fc0a003d644, flags=0x0 +2023-04-08 20:37:20.608+0000: 431151: debug : virDomainDispose:348 : release domain 0x7fc050007550 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.634+0000: 431150: debug : virDomainLookupByName:413 : conn=0x7fc0a8002ea0, name=guest-1 +2023-04-08 20:37:20.634+0000: 431150: debug : virDomainDispose:348 : release domain 0x7fbfc00072e0 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.634+0000: 431152: debug : virDomainBackupBegin:13040 : dom=0x7fc0500075f0, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), backupXML=<domainbackup><incremental>1680930625</incremental></domainbackup>, checkpointXML=<domaincheckpoint><name>1680986240</name></domaincheckpoint>, flags=0x0 +2023-04-08 20:37:20.667+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=none agentJob=none asyncJob=backup (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=none) +2023-04-08 20:37:20.667+0000: 431152: debug : qemuDomainObjBeginJobInternal:892 : Started async job: backup (vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.668+0000: 431152: debug : virStringMatch:662 : match '/home/vm/domains/guest-1/qemu.agent' for '^/var/lib/libvirt/qemu/channel/target/([^/]+\.)|(domain-[^/]+/)org\.qemu\.guest_agent\.0$' +2023-04-08 20:37:20.669+0000: 431152: debug : virStringMatch:662 : match '/home/vm/domains/guest-1/qemu.agent' for '^/var/lib/libvirt/qemu/channel/target/([^/]+\.)|(domain-[^/]+/)org\.qemu\.guest_agent\.0$' +2023-04-08 20:37:20.670+0000: 431152: debug : virStringMatch:662 : match '/home/vm/domains/guest-1/qemu.agent' for '^/var/lib/libvirt/qemu/channel/target/([^/]+\.)|(domain-[^/]+/)org\.qemu\.guest_agent\.0$' +2023-04-08 20:37:20.670+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:20.670+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.670+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.671+0000: 1882669: debug : qemuMonitorJSONIOProcessLine:222 : Line [{"return": [{"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 32212254720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 7361290240, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-format", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "dirty-bitmaps": [{"name": "1680930625", "recording": true, "persistent": true, "busy": false, "granularity": 65536, "count": 458293248}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}, {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 7882014720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "format": "file", "actual-size": 7361290240, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-storage", "backing_file_depth": 0, "drv": "file", "iops": 0, "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}], "id": "libvirt-39597736"}] +2023-04-08 20:37:20.671+0000: 1882669: debug : virJSONValueFromString:1691 : string={"return": [{"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 32212254720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 7361290240, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-format", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "dirty-bitmaps": [{"name": "1680930625", "recording": true, "persistent": true, "busy": false, "granularity": 65536, "count": 458293248}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}, {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 7882014720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "format": "file", "actual-size": 7361290240, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-storage", "backing_file_depth": 0, "drv": "file", "iops": 0, "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}], "id": "libvirt-39597736"} +2023-04-08 20:37:20.672+0000: 1882669: info : qemuMonitorJSONIOProcessLine:241 : QEMU_MONITOR_RECV_REPLY: mon=0x7fc0480048b0 reply={"return": [{"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 32212254720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 7361290240, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-format", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "dirty-bitmaps": [{"name": "1680930625", "recording": true, "persistent": true, "busy": false, "granularity": 65536, "count": 458293248}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}, {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 7882014720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "format": "file", "actual-size": 7361290240, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-storage", "backing_file_depth": 0, "drv": "file", "iops": 0, "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}], "id": "libvirt-39597736"} +2023-04-08 20:37:20.672+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.672+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.672+0000: 431152: debug : virStorageFileBackendFileInit:57 : initializing FS storage file 0x7fc0704b3740 (file:/home/vm/domains/guest-1/disk.qcow2.1680986240)[64055:108] +2023-04-08 20:37:20.672+0000: 431152: debug : qemuDomainStorageSourceAccessModify:7767 : src='/home/vm/domains/guest-1/disk.qcow2.1680986240' readonly=0 force_ro=0 force_rw=1 revoke=0 chain=0 +2023-04-08 20:37:20.672+0000: 431152: debug : virLockManagerLogParams:90 : key=name type=string value=guest-1 +2023-04-08 20:37:20.672+0000: 431152: debug : virDomainLockManagerAddImage:90 : Add disk /home/vm/domains/guest-1/disk.qcow2.1680986240 +2023-04-08 20:37:20.672+0000: 431152: debug : virLockManagerAddResource:325 : lock=0x7fc0a460ca40 type=0 name=/home/vm/domains/guest-1/disk.qcow2.1680986240 nparams=0 params=(nil) flags=0x0 +2023-04-08 20:37:20.683+0000: 431152: debug : virCommandRunAsync:2630 : About to run LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f -F /home/vm/domains/guest-1/disk.qcow2.1680986240 +2023-04-08 20:37:20.796+0000: 431151: debug : virDomainLookupByName:413 : conn=0x7fc0a80020a0, name=guest-1 +2023-04-08 20:37:20.893+0000: 431152: debug : qemuSetupImagePathCgroup:74 : Allow path /home/vm/domains/guest-1/disk.qcow2.1680986240, perms: rw +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431151: debug : virDomainDispose:348 : release domain 0x7fc014007240 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.894+0000: 431152: info : qemuMonitorSend:914 : QEMU_MONITOR_SEND_MSG: mon=0x7fc0480048b0 msg={"execute":"blockdev-add","arguments":{"driver":"file","filename":"/home/vm/domains/guest-1/disk.qcow2.1680986240","node-name":"libvirt-78-storage","auto-read-only":true,"discard":"unmap"},"id":"libvirt-39597737"} +2023-04-08 20:37:20.894+0000: 1882669: info : qemuMonitorIOWrite:402 : QEMU_MONITOR_IO_WRITE: mon=0x7fc0480048b0 buf={"execute":"blockdev-add","arguments":{"driver":"file","filename":"/home/vm/domains/guest-1/disk.qcow2.1680986240","node-name":"libvirt-78-storage","auto-read-only":true,"discard":"unmap"},"id":"libvirt-39597737"} +2023-04-08 20:37:20.895+0000: 1385058: debug : virDomainGetInfo:2444 : dom=0x7fc0ac001b80, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), info=0x7fc009ffa880 +2023-04-08 20:37:20.895+0000: 1385058: debug : virDomainDispose:348 : release domain 0x7fc0ac001b80 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.895+0000: 431149: debug : virDomainGetBlockInfo:6284 : dom=0x7fc068024100, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), info=0x7fc0b7100890, flags=0x0 +2023-04-08 20:37:20.895+0000: 431149: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=query agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=async nested agentJob=none async=backup) +2023-04-08 20:37:20.895+0000: 431149: debug : qemuDomainObjBeginJobInternal:867 : Waiting for job (vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.895+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.895+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.896+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:20.896+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.896+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.896+0000: 431149: debug : qemuDomainObjBeginJobInternal:867 : Waiting for job (vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.896+0000: 431152: info : qemuMonitorSend:914 : QEMU_MONITOR_SEND_MSG: mon=0x7fc0480048b0 msg={"execute":"blockdev-create","arguments":{"job-id":"create-libvirt-78-format","options":{"driver":"qcow2","file":"libvirt-78-storage","size":32212254720,"cluster-size":65536,"backing-file":"/home/vm/domains/guest-1/disk.qcow2","backing-fmt":"qcow2"}},"id":"libvirt-39597738"} +2023-04-08 20:37:20.896+0000: 1882669: info : qemuMonitorIOWrite:402 : QEMU_MONITOR_IO_WRITE: mon=0x7fc0480048b0 buf={"execute":"blockdev-create","arguments":{"job-id":"create-libvirt-78-format","options":{"driver":"qcow2","file":"libvirt-78-storage","size":32212254720,"cluster-size":65536,"backing-file":"/home/vm/domains/guest-1/disk.qcow2","backing-fmt":"qcow2"}},"id":"libvirt-39597738"} +2023-04-08 20:37:20.898+0000: 1882669: debug : qemuProcessHandleJobStatusChange:956 : job 'create-libvirt-78-format'(domain: 0x7fc0a4033a10,guest-1) state changed to 'created'(1) +2023-04-08 20:37:20.898+0000: 1882669: debug : qemuProcessHandleJobStatusChange:956 : job 'create-libvirt-78-format'(domain: 0x7fc0a4033a10,guest-1) state changed to 'running'(2) +2023-04-08 20:37:20.898+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.898+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.899+0000: 431149: debug : qemuDomainObjBeginJobInternal:883 : Started job: query (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.899+0000: 431149: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:21.432+0000: 1882669: debug : qemuProcessHandleAgentEOF:147 : Received EOF from agent on 0x7fc0a4033a10 'guest-1' +2023-04-08 20:37:21.432+0000: 1882669: debug : qemuMonitorIO:576 : Error on monitor Unable to read from monitor: Connection reset by peer mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.432+0000: 1882669: debug : qemuMonitorIO:609 : Triggering error callback mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.432+0000: 1882669: debug : qemuProcessHandleMonitorError:355 : Received error on 0x7fc0a4033a10 'guest-1' +2023-04-08 20:37:21.432+0000: 431149: debug : qemuMonitorSend:927 : Send command resulted in error Unable to read from monitor: Connection reset by peer mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.433+0000: 431149: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:21.433+0000: 1882669: debug : qemuMonitorIO:576 : Error on monitor Unable to read from monitor: Connection reset by peer mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.433+0000: 431149: debug : qemuDomainObjEndJob:1135 : Stopping job: query (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:21.433+0000: 1882669: debug : qemuMonitorIO:598 : Triggering EOF callback mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.433+0000: 1882669: debug : qemuProcessHandleMonitorEOF:310 : Received EOF on 0x7fc0a4033a10 'guest-1' +2023-04-08 20:37:21.433+0000: 431149: debug : virDomainDispose:348 : release domain 0x7fc068024100 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:21.433+0000: 620333: debug : qemuProcessKill:7931 : vm=0x7fc0a4033a10 name=guest-1 pid=1882665 flags=0x1 +2023-04-08 20:37:21.633+0000: 620333: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=destroy agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:21.633+0000: 620333: debug : qemuDomainObjBeginJobInternal:883 : Started job: destroy (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:21.634+0000: 620333: debug : processMonitorEOFEvent:4025 : Monitor connection to 'guest-1' closed without SHUTDOWN event; assuming the domain crashed +2023-04-08 20:37:21.634+0000: 620333: debug : qemuProcessStop:8014 : Shutting down vm=0x7fc0a4033a10 name=guest-1 id=814 pid=1882665, reason=crashed, asyncJob=none, flags=0x0 +2023-04-08 20:37:21.634+0000: 620333: debug : qemuDomainLogAppendMessage:6740 : Append log message (vm='guest-1' message='2023-04-08 20:37:21.634+0000: shutting down, reason=crashed +2023-04-08 20:37:22.617+0000: 620333: debug : qemuProcessKill:7931 : vm=0x7fc0a4033a10 name=guest-1 pid=1882665 flags=0x5 +2023-04-08 20:37:22.617+0000: 620333: debug : qemuDomainCleanupRun:7321 : driver=0x7fc07015c730, vm=guest-1 +2023-04-08 20:37:22.617+0000: 620333: debug : qemuProcessAutoDestroyRemove:8416 : vm=guest-1 +2023-04-08 20:37:22.617+0000: 620333: debug : virCloseCallbacksUnset:145 : vm=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f, cb=0x7fc09e3f9ba0 +``` + +If you need any further information just let me know. As per request, ping @pipo.sk +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1589 b/results/classifier/gemma3:12b/hypervisor/1589 new file mode 100644 index 00000000..703a8996 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1589 @@ -0,0 +1,11 @@ + +Crash when using qemu 8.0.0 version tcg mode +Description of problem: +Can I no longer use qemu in tcg mode? +When operating in tcg mode in all versions of 8.0.0, a crash occurs on the booting screen and the window closes (the window stops responding before closing). +Steps to reproduce: +1. Run qemu with -accel tcg option +2. enter the boot screen +3. The screen freezes and the window closes after a few seconds (at which point it becomes unresponsive) +Additional information: +I have not checked whether the same symptom occurs in Linux, and it occurs in all versions of 8.0.0 for Windows. diff --git a/results/classifier/gemma3:12b/hypervisor/1591 b/results/classifier/gemma3:12b/hypervisor/1591 new file mode 100644 index 00000000..0f149611 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1591 @@ -0,0 +1,2 @@ + +test-mmap (4096 byte pages) on arm fails on ppc64le host diff --git a/results/classifier/gemma3:12b/hypervisor/1594 b/results/classifier/gemma3:12b/hypervisor/1594 new file mode 100644 index 00000000..da7468fa --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1594 @@ -0,0 +1,22 @@ + +Wrong cpu information is still received when using whpx acceleration. +Description of problem: +I received wrong information the other day and registered an issue, but now the latest version has not been fixed and is delivering the same wrong information. +If not fixed, Windows Home version (Windows 11 Home version) cannot run more than 5 cores with whpx acceleration. +(If you boot after setting more than 5 cores, an incorrect CPU parameter BSOD occurs during booting, and Windows 11 home version seems to allow up to 4 physical CPUs..) +* Even if you explicitly give -smp cores=n,threads=1,sockets=1 and boot, it is ignored and recognized as a PC with n 1-core CPUs. +Steps to reproduce: +1. Run qemu with -accel whpx option +2. Check CPU information after booting is complete +3. Check the same CPU information after booting from a physical PC and other virtualization software (VMware, Virtual Box, etc.) +4. It has been confirmed that the number of physical CPUs and the number of cores per CPU are different from other virtualization software or physical PCs. (For example, when setting 4 cores, it is recognized as 1CPU 4Core in other virtualization software, but as 4CPU 1Core in qemu operated with whpx acceleration) +Additional information: +* The CPU was set to 4 cores, and the image was taken as a screenshot of the information recognized as the 4th processor by Linux. +> Linux CPU information booted from qemu (with whpx acceleration) +execution statement : qemu-system-x86_64 -M q35 -smp cores=4,threads=1,sockets=1 -m 4g -display sdl -drive file=test.vdi,id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -accel whpx (or 'qemu-system-x86_64 -M q35 -smp 4 -m 4g -display sdl -drive file=test.vdi,id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -accel whpx') + + + +> Linux CPU information booted from other virtualization software (Virtual Box) + + diff --git a/results/classifier/gemma3:12b/hypervisor/1594239 b/results/classifier/gemma3:12b/hypervisor/1594239 new file mode 100644 index 00000000..6267fd16 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1594239 @@ -0,0 +1,160 @@ + +After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error + +Description +=========== +Using virt-manager to create a VM in Aarch64, Ubuntu 16.04. +Add scsi disk to the VM. After add four or more scsi disks, start the VM and will got Qemu error. + +Steps to reproduce +================== +1.Use virt-manager to create a VM. +2.After the VM is started, add scsi disk to the VM. They will be allocated to "sdb,sdc,sdd....." . +3.If we got a disk name > sdg, virt-manager will also assign a virtio-scsi controller for this disk.And the VM will be shutdown. +4.Start the VM, will see the error log. + + +Expected result +=============== +Start the vm smoothly.The added disks can work. + +Actual result +============= +Got the error: +starting domain: internal error: process exited while connecting to monitor: qemu-system-aarch64: /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed. +details=Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in startup + self._backend.create() + File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1035, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: internal error: process exited while connecting to monitor: qemu-system-aarch64: /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed. + + +Environment +=========== +1. virt-manager version is 1.3.2 + +2. Which hypervisor did you use? + Libvirt+KVM + $ kvm --version + QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), Copyright (c) 2003-2008 Fabrice Bellard + $ libvirtd --version + libvirtd (libvirt) 1.3.1 + +3. Which storage type did you use? + In the host file system,all in one physics machine. +stack@u202154:/opt/stack/nova$ df -hl +Filesystem Size Used Avail Use% Mounted on +udev 7.8G 0 7.8G 0% /dev +tmpfs 1.6G 61M 1.6G 4% /run +/dev/sda2 917G 41G 830G 5% / +tmpfs 7.9G 0 7.9G 0% /dev/shm +tmpfs 5.0M 0 5.0M 0% /run/lock +tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup +/dev/sda1 511M 888K 511M 1% /boot/efi +cgmfs 100K 0 100K 0% /run/cgmanager/fs +tmpfs 1.6G 0 1.6G 0% /run/user/1002 +tmpfs 1.6G 0 1.6G 0% /run/user/1000 +tmpfs 1.6G 0 1.6G 0% /run/user/0 + +4. Environment information: + Architecture : AARCH64 + OS: Ubuntu 16.04 + +The Qemu commmand of libvirt is : +2016-06-20 02:39:46.561+0000: starting up libvirt version: 1.3.1, package: 1ubuntu10 (William Grant <email address hidden> Fri, 15 Apr 2016 12:08:21 +1000), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), hostname: u202154 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name cent7 -S -machine virt,accel=kvm,usb=off -cpu host -drive file=/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/cent7_VARS.fd,if=pflash,format=raw,unit=1 -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid d5462bb6-159e-4dbd-9266-bf8c07fa1695 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-cent7/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device virtio-scsi-device,id=scsi0 -device lsi,id=scsi1 -device lsi,id=scsi2 -device virtio-scsi-device,id=scsi3 -usb -drive file=/var/lib/libvirt/images/cent7-2.img,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -drive file=/var/lib/libvirt/images/cent7-10.img,format=qcow2,if=none,id=drive-scsi0-0-0-2 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2 -drive file=/var/lib/libvirt/images/cent7-11.img,format=qcow2,if=none,id=drive-scsi0-0-0-3 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-0-3,id=scsi0-0-0-3 -drive file=/var/lib/libvirt/images/cent7-13.img,format=qcow2,if=none,id=drive-scsi3-0-0-0 -device scsi-hd,bus=scsi3.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi3-0-0-0,id=scsi3-0-0-0 -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=35 -device virtio-net-device,netdev=hostnet0,id=net0,mac=52:54:00:a1:6e:75 -serial pty -msg timestamp=on +Domain id=11 is tainted: host-cpu + +The libvirt xml is: +<domain type='kvm'> + <name>cent7</name> + <uuid>d5462bb6-159e-4dbd-9266-bf8c07fa1695</uuid> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>2</vcpu> + <os> + <type arch='aarch64' machine='virt'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw</loader> + <nvram>/var/lib/libvirt/qemu/nvram/cent7_VARS.fd</nvram> + <boot dev='hd'/> + </os> + <cpu mode='host-passthrough'/> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/cent7-2.img'/> + <target dev='sda' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='sdb' bus='scsi'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/cent7-10.img'/> + <target dev='sdc' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='2'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/cent7-11.img'/> + <target dev='sdd' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='3'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/cent7-13.img'/> + <target dev='sdv' bus='scsi'/> + <address type='drive' controller='3' bus='0' target='0' unit='0'/> + </disk> + <controller type='scsi' index='0' model='virtio-scsi'> + <address type='virtio-mmio'/> + </controller> + <controller type='scsi' index='1'> + <address type='virtio-mmio'/> + </controller> + <controller type='scsi' index='2'> + <address type='virtio-mmio'/> + </controller> + <controller type='scsi' index='3' model='virtio-scsi'> + <address type='virtio-mmio'/> + </controller> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='dmi-to-pci-bridge'> + <model name='i82801b11-bridge'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </controller> + <controller type='pci' index='2' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='2'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:a1:6e:75'/> + <source bridge='br0'/> + <model type='virtio'/> + <address type='virtio-mmio'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + </devices> +</domain> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1600 b/results/classifier/gemma3:12b/hypervisor/1600 new file mode 100644 index 00000000..b64f67c1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1600 @@ -0,0 +1,26 @@ + +Aarch64/FEAT_SEL2 secure S1 translation for a NS page resolves to the secure IPA space +Description of problem: +Follow up to https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmware.org/thread/ZUHRGWVDPUQ5CK6SRWZ7AMI5IKVS6J47/ + +In context of Hafnium project (SEL2 / SPM firmware), implementing secure/non-secure page tables split rooted by VTTBR/VSTTBR in TZ secure world. +Observing transactions always resolve to the secure IPA space (hence to the page tables rooted to by VSTTBR) whichever the state of the S1 MMU translation NS bit. +Access to a page mapped NS from the SEL1 Trusted OS, causes a S2 page fault even though mapped in page tables rooted to by VTTBR. + +The VTCR_EL2/VSTCR_EL2 settings at SEL2 are as follows: +VTCR_EL2.NSA/NSW=10b +VSTCR_EL2.SA/SW=00b + +Note the same set of changes (https://review.trustedfirmware.org/q/topic:%2522od/split-vttbr%2522+status:open) run fine for the same scenario on FVP. +Steps to reproduce: +1. build qemu master 60ca584b8af0de525656f959991a440f8c191f12 +2. unzip [qemu-sel2-vttbr-fail.zip](/uploads/ec556347c32d97f79c140c5bccf45c6b/qemu-sel2-vttbr-fail.zip) +3. Run + +``` +<...>/qemu/build/aarch64-softmmu/qemu-system-aarch64 -nographic -serial file:uart0.log -serial file:uart1.log -smp 2 -machine virt,secure=on,mte=on,gic-version=3,virtualization=true -cpu max,sme=off,pauth-impdef=on -d unimp -semihosting-config enable=on,target=native -m 1057 -bios bl1.bin -initrd rootfs.cpio.gz -kernel Image -no-acpi -append 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2 nokaslr' -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000 -netdev user,id=vmnic -device virtio-net-device,netdev=vmnic +``` +Additional information: +[qemu-60ca58-qemu-tfa-hf-linux-fail.txt](/uploads/1db0155fc49140cf52913cd75b7494c1/qemu-60ca58-qemu-tfa-hf-linux-fail.txt) illustrates the failure, linux boot stops, after sharing a NS page to the TOS, and the TOS retrieving the page, mapping as NS and accessing it (ends in a dead loop, because of the S2 PF in the TOS). + +[qemu-tfa-hf-linux-pass.txt](/uploads/4e672617838e40fe3614c127531443b5/qemu-tfa-hf-linux-pass.txt) shows the expected output where the NS mem sharing operation succeeds. diff --git a/results/classifier/gemma3:12b/hypervisor/1603 b/results/classifier/gemma3:12b/hypervisor/1603 new file mode 100644 index 00000000..c138fb8a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1603 @@ -0,0 +1,74 @@ + +Regression in v8.0.0-rc1: `Abort trap: 6` during `hvf/x86_emu.c:exec_mov()` (`-cpu host` + UEFI) +Description of problem: +`qemu-system-x86_64 -accel hvf -cpu host -drive <UEFI>` crashes. +Steps to reproduce: +```console +$ qemu-system-x86_64 -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd +vmx_read_mem: mmu_gva_to_gpa ffc00000 failed +Abort trap: 6 +``` +Additional information: +This is a regression in v8.0.0-rc1. + +- v8.0.0-rc0: works +- v8.0.0-rc1: crashes +- ... +- v8.0.0-rc4: crashes + + +Backtrace: +```console +$ lldb /usr/local/bin/qemu-system-x86_64 +(lldb) target create "/usr/local/bin/qemu-system-x86_64" +Current executable set to '/usr/local/bin/qemu-system-x86_64' (x86_64). +(lldb) process handle SIGUSR2 -s false -p true +NAME PASS STOP NOTIFY +=========== ======= ======= ======= +SIGUSR2 true false not set +(lldb) run -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd +Process 17627 launched: '/usr/local/bin/qemu-system-x86_64' (x86_64) +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +2023-04-14 17:16:22.879194+0900 qemu-system-x86_64[17627:1529741] [Window] Warning: Window NSWindow 0x10391def0 ordered front from a non-active application and may order beneath the active application's windows. +vmx_read_mem: mmu_gva_to_gpa ffc00000 failed +Process 17627 stopped +* thread #4, stop reason = signal SIGABRT + frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10 +libsystem_kernel.dylib`: +-> 0x7ff8121331f2 <+10>: jae 0x7ff8121331fc ; <+20> + 0x7ff8121331f4 <+12>: movq %rax, %rdi + 0x7ff8121331f7 <+15>: jmp 0x7ff81212ccdb ; cerror_nocancel + 0x7ff8121331fc <+20>: retq +Target 0: (qemu-system-x86_64) stopped. +(lldb) bt +* thread #4, stop reason = signal SIGABRT + * frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10 + frame #1: 0x00007ff81216aee6 libsystem_pthread.dylib`pthread_kill + 263 + frame #2: 0x00007ff812091b45 libsystem_c.dylib`abort + 123 + frame #3: 0x0000000100223608 qemu-system-x86_64`vmx_read_mem + 201 + frame #4: 0x000000010021fa5b qemu-system-x86_64`read_val_ext + 65 + frame #5: 0x000000010021fc02 qemu-system-x86_64`fetch_operands + 197 + frame #6: 0x0000000100220f8b qemu-system-x86_64`exec_mov + 31 + frame #7: 0x0000000100220f01 qemu-system-x86_64`exec_instruction + 48 + frame #8: 0x000000010021c81f qemu-system-x86_64`hvf_vcpu_exec + 4144 + frame #9: 0x000000010033fa53 qemu-system-x86_64`hvf_cpu_thread_fn + 270 + frame #10: 0x0000000100492e49 qemu-system-x86_64`qemu_thread_start + 130 + frame #11: 0x00007ff81216b1d3 libsystem_pthread.dylib`_pthread_start + 125 + frame #12: 0x00007ff812166bd3 libsystem_pthread.dylib`thread_start + 15 +(lldb) +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1605 b/results/classifier/gemma3:12b/hypervisor/1605 new file mode 100644 index 00000000..1cb62ba8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1605 @@ -0,0 +1,39 @@ + +On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c +Description of problem: +On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c +- qemu windows crashes during data copy + ```D:\tmpq\qemu\8.0.0-rc4\qemu\qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -bios D:\vstorage\win_m01_edk2-x8_64.fd -boot c -drive "index=0,if=virtio,media=disk,format=raw,file=D:\vstorage\m01_bootnoefi.raw.img" -drive "index=1,if=virtio,media=disk,format=raw,file=F:\m01_lnx.raw.img.vtoy" -drive "index=2,if=virtio,media=disk,format=vhdx,file=F:\gkpics01.vhdx" -drive "index=3,if=virtio,media=disk,format=vhdx,file=D:\test\sgdata.vhdx" -display sdl -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15,hostfwd=tcp::9551-:22 -device virtio-net,netdev=vmnic1 -chardev qemu-vdagent,id=ch1,name=vdagent,clipboard=on -device virtio-serial -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -qmp "tcp:127.0.0.1:5955,server,nowait"``` + ``` ``` + ```Windows Hypervisor Platform accelerator is operational``` + ```Unexpected error in bdrv_check_qiov_request() at ../../../block/io.c:815:``` + ```D:\tmpq\qemu\8.0.0-rc4\qemu\qemu-system-x86_64.exe: offset is negative: -28983296``` + +. +- The **LINE NUMBER** : https://gitlab.com/qemu-project/qemu/-/blob/master/block/io.c#L815 +- qemu setup is ```qemu-w64-setup-20230414.exe ``` +Steps to reproduce: +1. have fresh vhdx ready create a vhdx in ```diskmgmt``` (also attached to [comment](https://gitlab.com/qemu-project/qemu/-/issues/727#note_1346341805)) +2. have vhdx with synthetic generated data ready (see process to generate sgdata in [comment](https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694) ) +3. start qemu, login, open terminal +4. Inside VM, start a terminal window, sudo root, +5. open```gdisk /dev/vdc``` create a ntfs partition +6. format as ntfs: ```mkfs.ntfs -Q -L fs_gkpics01 /dev/vdc1``` +7. mount the partition ```mount -t ntfs3 /dev/vdc1 /mnt/a -o uid=1000,gid=1000,defaults,umask=0002``` +8. mount the partition ```mount -t ntfs3 /dev/vdd2 /mnt/b -o uid=1000,gid=1000,defaults,umask=0002``` +9. In a user login, do rsync data-copy step + ```( fl="photos001" ; src="/mnt/b/sgdata" ; dst="/mnt/a" ; sdate=`date` ; echo "$sdate" ; cd "$src" ; rsync -avH "$fl" "$dst" ; echo "$sdate" ; date ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "rsync $src/$fl" )``` + + +The bug is easily reproducible. +The moment of the crash may seems spurious, but is almost certainly bound to happen. +When it happens, it can be seen to be the same error message. +Sometimes the crash happens in ```gdisk``` step, sometimes during ```mkfs.ntfs``` sometimes partway through the ```rsync```-copy, not very long into it. +Additional information: +- This has been happening for some time. I haven't used/tested vhdx much in windows much since 7.0.0 on account of other corruption bugs/lack of dependability. +- This does not happen in Linux, as tested in #727 +- The fix of #727 is unrelated to this. It doesn't have the same feel/reproduction intuitive-signature. + - Happens before (on doing the same test) + - on 8.0.0-rc1 (line number of io.c there is L811) + - on 7.2.0 (line no of io.c there is [L971](https://gitlab.com/qemu-project/qemu/-/blob/ace5a161ea1c09d8eaa8b2a717528457dc924e83/block/io.c#L971)) +- It may be caused by other changes going into block code since 7.0 . diff --git a/results/classifier/gemma3:12b/hypervisor/1608 b/results/classifier/gemma3:12b/hypervisor/1608 new file mode 100644 index 00000000..bafe7a9f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1608 @@ -0,0 +1,2 @@ + +QEMU gives wrong MPIDR value for Arm CPU types with MT=1 diff --git a/results/classifier/gemma3:12b/hypervisor/1617 b/results/classifier/gemma3:12b/hypervisor/1617 new file mode 100644 index 00000000..13c0e4ac --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1617 @@ -0,0 +1,63 @@ + +RISC-V: VS external IRQ can be taken in M-mode +Description of problem: +The RISC-V specification states that `VS-level interrupts and guest external interrupts are always delegated past M-mode to HS mode.` +I happened to come across a situation where QEMU takes the vs_external IRQ in machine mode. +Steps to reproduce: +1. Enable IRQs globally (mstatus, vsstatus) +2. Set hstatus.VGEIN to a legal value +3. Write -1 to mie +4. Write -1 to hvip + +I included a binary that should be able to reproduce the issue. + +I use a vectored setup for mtvec and as soon as the VSEIP bit in hvip has been set the machine jumps to mtvec.vsei. +To confirm that I actually went to mtvec and not somewhere with a faulty print I also performed an ecall and that was reported as an M mode ecall. +Additional information: +``` +TRACE: [hart_ctrl.c:35] STARTING CPU 0 +DEBUG: [trap_handling.c: 886] Setting up trap handlers +DEBUG: [aia_ctrl.c: 377] Initializing interrupt controller +TRACE: [main.c:31] Writing -1 to mie +TRACE: [main.c:33] Writing -1 to hvip +riscv_cpu_do_interrupt: hart:0, async:1, cause:000000000000000a, epc:0x0000000080000114, tval:0x0000000000000000, desc=vs_external +ERROR: [trap_handling.c:280] mtvec_vsei should be unreachable +mstatus = 0x0000000a000038a2 hstatus: + SIE = 1 VSXL[1:0] = 2 + MIE = 0 VTSR = 0 + SPIE = 1 VTW = 0 + UBE = 0 VTVM = 0 + MPIE = 1 VGEIN[5:0] = 1 + SPP = 0 HU = 0 + VS = 0 SPVP = 0 + MPP = 3 SPV = 0 + FS = 1 GVA = 0 + MPRV = 0 VSBE = 0 + SUM = 0 + MXR = 0 + TVM = 0 + TW = 0 + TSR = 0 + UXL = 2 + SXL = 2 + SBE = 0 + MBE = 0 + GVA = 0 + MPV = 0 +mie mip mideleg hvip + ssie (1) = 1 ssip (1) = 0 ssi (1) = 0 ssip (1) = 0 + vssie(2) = 1 vssip(2) = 1 vssi (2) = 0 vssip(2) = 1 + msie (3) = 1 msip (3) = 0 msi (3) = 0 msip (3) = 0 + stie (5) = 1 stip (5) = 0 sti (5) = 0 stip (5) = 0 + vstie(6) = 1 vstip(6) = 0 vsti (6) = 0 vstip(6) = 0 + mtie (7) = 1 mtip (7) = 0 mti (7) = 0 mtip (7) = 0 + seie (9) = 1 seip (9) = 0 sei (9) = 0 seip (9) = 0 + vseie(10) = 1 vseip(10) = 1 vsei (10) = 0 vseip(10) = 1 + meie (11) = 1 meip (11) = 0 mei (11) = 0 meip (11) = 0 + sgeie(12) = 1 sgeip(12) = 0 sgei (12) = 0 sgeip(12) = 0 +DEBUG: [trap_handling.c: 28] hart_ctrl.kill_hart = 0x8000a00c +TRACE: [trap_handling.c:29] Program done, exiting +QEMU: Terminated +``` +Reproducer of the problem: +[main](/uploads/26a5698ce948149ca9d34f6b3dfac6a4/main) diff --git a/results/classifier/gemma3:12b/hypervisor/1621 b/results/classifier/gemma3:12b/hypervisor/1621 new file mode 100644 index 00000000..24b72f63 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1621 @@ -0,0 +1,107 @@ + +QCOW2 image grows over 110% of its virtual size +Description of problem: +Follow-up of https://github.com/oVirt/vdsm/issues/371 + +As oVirt divides a iSCSI LUN into a LVM device and each VM disk is a Logical Volume, the qcow2 images are inside a LV. +This works fine, and oVirt allows the LV to grow to 110% of its virtual size. + +Now we have like 1 time each month the issue that a VM tries to grow over its 110% limit, which should never happen. +Steps to reproduce: +1. When it happend in production, I copied the LV via dd to some file. +2. I copied the file to a new LV on a test machine, and created a VM for it +3. Start the VM +4. Issue reoccurs directly +Additional information: +So I started some gdb'ing on the pid, and this it what seems to happen: +``` +#16 0x0000563c60921f25 in qcow2_add_task (bs=bs@entry=0x563c62bb8090, pool=pool@entry=0x0, func=func@entry=0x563c60924860 <qcow2_co_pwritev_task_entry>, subcluster_type=subcluster_type@entry=QCOW2_SUBCLUSTER_UNALLOCATED_PLAIN, host_offset=17718824960, offset=offset@entry=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=0, l2meta=0x7f84c401c600) + at ../block/qcow2.c:2249 + local_task = {task = {pool = 0x0, func = 0x563c60924860 <qcow2_co_pwritev_task_entry>, ret = 0}, bs = 0x563c62bb8090, subcluster_type = QCOW2_SUBCLUSTER_UNALLOCATED_PLAIN, host_offset = 17718824960, offset = 15192346624, bytes = 1310720, qiov = 0x7f84c4003a70, qiov_offset = 0, l2meta = 0x7f84c401c600} + task = 0x7f82bafffb00 +#17 0x0000563c609225b7 in qcow2_co_pwritev_part (bs=0x563c62bb8090, offset=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=0, flags=<optimized out>) at ../block/qcow2.c:2645 + s = 0x563c62bbf990 + offset_in_cluster = <optimized out> + ret = <optimized out> + cur_bytes = 1310720 + host_offset = 17718824960 + l2meta = 0x7f84c401c600 + aio = 0x0 +#18 0x0000563c6090395b in bdrv_driver_pwritev (bs=bs@entry=0x563c62bb8090, offset=offset@entry=15192346624, bytes=bytes@entry=1310720, qiov=qiov@entry=0x7f84c4003a70, qiov_offset=qiov_offset@entry=0, flags=flags@entry=0) at ../block/io.c:1248 + drv = 0x563c6125fb20 <bdrv_qcow2> + sector_num = <optimized out> + nb_sectors = <optimized out> + local_qiov = {iov = 0x563c6125fb20 <bdrv_qcow2>, niov = 8192, {{nalloc = 4096, local_iov = {iov_base = 0x563c62bb8090, iov_len = 0}}, {__pad = "\000\020\000\000\000\000\000\000\220\200\273b", size = 0}}} + ret = <optimized out> + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#19 0x0000563c60905872 in bdrv_aligned_pwritev (child=0x563c647f3c10, req=0x7f82bafffe30, offset=15192346624, bytes=1310720, align=<optimized out>, qiov=0x7f84c4003a70, qiov_offset=0, flags=0) at ../block/io.c:2122 + bs = 0x563c62bb8090 + drv = 0x563c6125fb20 <bdrv_qcow2> + ret = <optimized out> + bytes_remaining = 1310720 + max_transfer = <optimized out> + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#20 0x0000563c6090622b in bdrv_co_pwritev_part (child=0x563c647f3c10, offset=<optimized out>, offset@entry=15192346624, bytes=<optimized out>, bytes@entry=1310720, qiov=<optimized out>, qiov@entry=0x7f84c4003a70, qiov_offset=<optimized out>, qiov_offset@entry=0, flags=flags@entry=0) at ../block/io.c:2310 + bs = <optimized out> + req = {bs = 0x563c62bb8090, offset = 15192346624, bytes = 1310720, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 15192346624, overlap_bytes = 1310720, list = {le_next = 0x7f829c6c8e30, le_prev = 0x7f82a3fffe60}, co = 0x7f84c4004210, wait_queue = {entries = {sqh_first = 0x0, sqh_last = 0x7f82bafffe78}}, waiting_for = 0x0} + align = <optimized out> + pad = {buf = 0x0, buf_len = 0, tail_buf = 0x0, head = 0, tail = 0, merge_reads = false, local_qiov = {iov = 0x0, niov = 0, {{nalloc = 0, local_iov = {iov_base = 0x0, iov_len = 0}}, {__pad = '\000' <repeats 11 times>, size = 0}}}} + ret = <optimized out> + padded = false + __PRETTY_FUNCTION__ = "bdrv_co_pwritev_part" +#21 0x0000563c608f71e0 in blk_co_do_pwritev_part (blk=0x563c648183c0, offset=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=qiov_offset@entry=0, flags=0) at ../block/block-backend.c:1289 + ret = <optimized out> + bs = 0x563c62bb8090 +``` + +There is a write from the VM with size 1310720 on offset 15192346624. +A host offset is calculated for this, but this offset is 17718824960 !! +The image/LV is only 17716740096, and 17716740096 < 17718824960 -> ENOSPC error is triggered. + +The code for calculating the host offset seems to be untouched for the last years. +But it seems like for some reason it takes some offset way beyond the virtual size boundaries. + +The qemu-img output: +``` +# qemu-img info /dev/mapper/test-xxxxx +image: /dev/mapper/test-xxxxx +file format: qcow2 +virtual size: 15 GiB (16106127360 bytes) +disk size: 0 B +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + bitmaps: + [0]: + flags: + [0]: in-use + [1]: auto + name: 428fae80-3892-4083-9107-51fb76a7f06b + granularity: 65536 + [1]: + flags: + [0]: in-use + [1]: auto + name: 51ccd1fc-08a4-485d-8c04-0eb750665e05 + granularity: 65536 + [2]: + flags: + [0]: in-use + [1]: auto + name: 19796bed-56a5-44c1-a7f2-dae633e65c87 + granularity: 65536 + [3]: + flags: + [0]: in-use + [1]: auto + name: 13056186-e65e-448e-a3c3-019ab25d3a27 + granularity: 65536 + refcount bits: 16 + corrupt: false + extended l2: false +``` + +Also attaching the map where you can see there are plenty of zero blocks, but still it tries to allocate a new block for some reason. +[map.txt](/uploads/0890cf718f77c0ad2e562165eb350d13/map.txt) diff --git a/results/classifier/gemma3:12b/hypervisor/1623 b/results/classifier/gemma3:12b/hypervisor/1623 new file mode 100644 index 00000000..20cd6eba --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1623 @@ -0,0 +1,10 @@ + +vec_lde and vec_expte semi-randomly produce the wrong results +Description of problem: +I found that while implementing the Altivec support for the rust [stdarch](https://github.com/rust-lang/stdarch). +Steps to reproduce: +1. Install rust nightly (e.g. using https://rustup.rs/) +2. `git clone https://github.com/rust-lang/stdarch` +3. You need to either cross compile or compile and run the tests for `crates/core_arch`. +Additional information: +Both `valgrind` and running on power9 produce the correct results diff --git a/results/classifier/gemma3:12b/hypervisor/1627 b/results/classifier/gemma3:12b/hypervisor/1627 new file mode 100644 index 00000000..9e5eb501 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1627 @@ -0,0 +1,40 @@ + +Aarch64: VTCR.T0SZ / iasize test for Aarch32 guests wrong +Description of problem: +With QEMU 8 we are no longer able to execute Aarch32 guest code on an Aarch64 host. We use virtualization for the QEMU guest: +- The QEMU guest kernel (L4Re kernel) runs at EL2 in AArch64 mode. +- The L4Re guest code runs at EL1 in AAarch32 mode. + +It seems that the check for T0SZ / iasize in `ptw.c` / `check_s2_mmu_setup()` is too strict: +``` +if (is_aa64) { + /* + * AArch64.S2InvalidTxSZ: While we checked tsz_oob near the top of + * get_phys_addr_lpae, that used aa64_va_parameters which apply + * to aarch64. If Stage1 is aarch32, the min_txsz is larger. + * See AArch64.S2MinTxSZ, where min_tsz is 24, translated to + * inputsize is 64 - 24 = 40. + */ + if (iasize < 40 && !arm_el_is_aa64(&cpu->env, 1)) { + goto fail; + } +``` +The above test fails for us when executing Aarch32 EL1 code on Aarch64 EL2. + +Please note that the comment talks about `S2MinTxSZ` / `min_tsz`, so if the **minimum** value of `T0SZ` is 24, then the **maximum** value of `iasize` is `64-24=40` so the following comparison would be more appropriate (I replaces `<` by `>`): +``` +if (iasize > 40 && !arm_el_is_aa64(&cpu->env, 1)) { + goto fail; +} +``` +However, the minimum value of `VTCR_EL2.T0SZ` is either 16 or 12, see `VTCR_EL2.DS`: +- `VTCR_EL2.DS=0b0`: **minimum** value of `VTCR_EL2.T0SZ` is 16 => **maximum** value of `iasize` is 48, +- `VTCR_EL2.DS=0b1`: **minimum** value of `VTCR_EL2.T0SZ` is 12 => **maximum** value of `iasize` is 52. + +Regarding the minimum of `iasize` / maximum of `VTCR_EL2.T0SZ`, see `ID_AA64MMFR_EL1.ST`: +- `ID_AA64MMFR2_EL1.ST=0b0000`: **maximum** value of `VTCR_EL2.T0SZ` is 39 => **minimum** value of `iasize` is 25, +- `ID_AA64MMFR2_EL1.ST=0b0001`: **maximum** value of `VTCR_EL2.T0SZ` is 48 => **minimum** value of `iasize` is 16 (or 47/17 for 64KiB granules). + +Our system executes Aarch32 EL1 code fine on Aarch64 EL2 if I weaken the comparison. +Additional information: +Sorry for not providing a test build but I'm not sure if it's worth to provide a custom build of our L4Re system, but I will happily provide one if you insist. diff --git a/results/classifier/gemma3:12b/hypervisor/1631 b/results/classifier/gemma3:12b/hypervisor/1631 new file mode 100644 index 00000000..038afe0c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1631 @@ -0,0 +1,18 @@ + +[8.0.0] Host MacOS 13.3.1 – does not work or works incorrectly +Description of problem: +WINXP x86 - freezes before logging in on ARM macOS 13.3.1 host + +WINXP x86 - works but slowly x86_64 macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after start on ARM macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after selecting grub boot option + +**On qemu 7.2.1 all works perfectly!!!** +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1635695 b/results/classifier/gemma3:12b/hypervisor/1635695 new file mode 100644 index 00000000..20e2a54d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1635695 @@ -0,0 +1,9 @@ + +ovmf + smp + hyper-v + windows 7: doesn't work + +- using ovmf +- enable smp (>1 processors/cores) +- enable hyper-v features (eg. -cpu Haswell,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff) +- try to boot or install windows 7 x64 + +Result: black screen and hangs \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1645 b/results/classifier/gemma3:12b/hypervisor/1645 new file mode 100644 index 00000000..9a347a06 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1645 @@ -0,0 +1,9 @@ + +qemu error `hotplug memory" error="QMP command failed: a used vhost backend has no free memory slots left"` +Description of problem: +When I create a Qemu VM with 8 Gpus and hot-plugging memory, this will return the error QMP command failed: a used vhost backend has no free memory slots left. I read some source file https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost-user.c#L2077, and debug show u->user->memory_slots is 32, but this https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost.c#L62 used_memslots is bigger than u->user->memory_slots. `u->user->memory_slots` is defined 32 by https://gitlab.com/qemu-project/qemu/-/blob/master/subprojects/libvhost-user/libvhost-user.h#L37, but I also see VHOST_USER_MAX_RAM_SLOTS defined 512 under x86 architecture. Can I improve `u->user->memory_slots` by any way? +Steps to reproduce: +1.crate kata containers with 8 Gpus +2.kata containers return error +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1646 b/results/classifier/gemma3:12b/hypervisor/1646 new file mode 100644 index 00000000..30003bb0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1646 @@ -0,0 +1,62 @@ + +fstrim dont work after live migrate +Description of problem: +We have use lvm thin pool and after live migration non-shared storage fstrim cannot free data usage Data% without reboot, after reboot fstim work fine + +``` + LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert + p639937 vm Vwi-aotz-- 30.00g pool 99.35 + +virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"minimum":0,"path":"/","trimmed":0}]}} + +virsh shutdown p639937 +Domain 'p639937' is being shutdown + +virsh start p639937 +Domain 'p639937' started + +virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"minimum":0,"path":"/","trimmed":29178654720}]}} + +lvs|grep p639937 + p639937 vm Vwi-aotz-- 30.00g pool 9.58 +``` + +On source host before migration: +``` + LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert + p639937 vm Vwi-a-tz-- 30.00g pool 9.48 +``` + +migration script +``` +SSH_OPTS='-o StrictHostKeyChecking=no -o PasswordAuthentication=no ' +MIGR_OPTS="--live --copy-storage-all --verbose --persistent --undefinesource" +ssh $SSH_OPTS $HOST -t "[ -b /dev/vm/$ACCT ] || /usr/sbin/lvcreate -V${SIZE}G -T vm/pool -n$ACCT" || f_print_err "Error: creation lvm" +virsh migrate $MIGR_OPTS $ACCT qemu+ssh://$SERV/system tcp://local.$SERV/ || f_print_err "Error on step: virsh migrate" +echo "Waiting for trim start..." +sleep 10 +ssh $SSH_OPTS $HOST -t "/usr/bin/virsh qemu-agent-command $ACCT --timeout 60 '{\"execute\":\"guest-fstrim\"}' >/dev/null 2>&1" +``` + +Disc config: +``` + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='threads' discard='unmap'/> + <source dev='/dev/vm/p639937'/> + <backingStore/> + <target dev='sda' bus='scsi'/> + <iotune> + <write_bytes_sec>104857600</write_bytes_sec> + <write_bytes_sec_max>524288000</write_bytes_sec_max> + <write_bytes_sec_max_length>120</write_bytes_sec_max_length> + </iotune> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> +``` + +Sometimes trimming working after migration, bit this is very rare. +We have try rescanning disc, drop caches on vm after migration, but didnt help. + +Inside vm's ext4 fs and almalinux 8/ubuntu 20+/debian 10-11 diff --git a/results/classifier/gemma3:12b/hypervisor/1647 b/results/classifier/gemma3:12b/hypervisor/1647 new file mode 100644 index 00000000..cb81e3a5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1647 @@ -0,0 +1,13 @@ + +Potential Bug in RISCV Hypervisor Extension: Timer Interrupt Handling in QEMU v8.0.0-rc1 +Steps to reproduce: +1. Build and run a simple hypervisor on QEMU v8.0.0-rc1 with the hypervisor extension feature of RISCV. +2. Set up hideleg, henvcfg, etc., in hypervisor and run the Linux kernel. +3. Observe the issue of infinite loop caused by the pending timer interrupt. +Additional information: +Linux version: riscv_aia_v1 from github.com/avpatel/linux +OpenSBI version: Modified 1.1 + +I would greatly appreciate it if you could kindly provide some guidance. Is this behavior expected or could this be a bug? I've tried to provide a detailed analysis of my observations, but I'm not 100% certain if my understanding is correct. + +Thank you for your time and consideration. diff --git a/results/classifier/gemma3:12b/hypervisor/1670 b/results/classifier/gemma3:12b/hypervisor/1670 new file mode 100644 index 00000000..8a0d8caf --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1670 @@ -0,0 +1,10 @@ + +Cannot statically build x86_64-softmmu with Darwin(Intel) +Description of problem: +I am using `Podman` and currently,`Podman` uses qemu on macOS. The `Podman` team has adopted a scheme to dynamically compile `qemu` (https://github.com/containers/podman-machine-qemu). However, I am currently trying to use static compilation for both amd64 and arm64 targets. + +I have searched many articles online, most of which are about static compilation on Linux. Very few articles mention static compilation on macOS, and some mention that `softmmu` does not support static compilation. However, I have not found any concrete evidence to support this claim. + +I also want to ask another question: Does `qemu` support static compilation on macOS? +Additional information: +[meson-log.txt](/uploads/6e32691488533a06c64dc34ee4514135/meson-log.txt) diff --git a/results/classifier/gemma3:12b/hypervisor/1672 b/results/classifier/gemma3:12b/hypervisor/1672 new file mode 100644 index 00000000..040d5852 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1672 @@ -0,0 +1,9 @@ + +failed to migrate using multifd with multifd-channels larger than 2 +Description of problem: +try to using multifd live migration on QEMU v8.0.0 using multifd channels larger than 2, but failed. +Steps to reproduce: +1. start source / dest qemu vm +2. migrate_set_capability multifd on && migrate_set_parameter multifd-channels 8 + +then live migration will failed diff --git a/results/classifier/gemma3:12b/hypervisor/1677 b/results/classifier/gemma3:12b/hypervisor/1677 new file mode 100644 index 00000000..2d290dab --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1677 @@ -0,0 +1,14 @@ + +qemu-system-x86_64 cannot run on Windows when -smp is specified with a value higher than `1`. An important argument for any expectation of VM performance +Description of problem: +qemu-system-x86_64 seems to crash on Windows the moment you try to use -smp to define more vcpus, even the basic usage of `-smp 4` will cause qemu to segfault after the guest's boot option is selected. +Steps to reproduce: +1. `qemu-system-x86_64 -smp 4 -cdrom rhel-9.2-x86_64-dvd.iso -drive if=pflash,format=raw,unit=0,readonly=on,file=edk2-x64/OVMF_CODE.fd -m 6G -nodefaults -serial mon:stdio` +2. Select the boot option to begin your installation +3. qemu hangs for 10 or so seconds then throws a Segmentation Fault. +Additional information: +1. This does not happen if -smp arguments are omitted, but running VMs with a single vcpu thread is slow and painful. +2. This still happens even without OVMF (Traditional bios booting) +3. This still happens even without -defaults and without a serial device + +Only output from qemu at death is `Segmentation fault` diff --git a/results/classifier/gemma3:12b/hypervisor/1680 b/results/classifier/gemma3:12b/hypervisor/1680 new file mode 100644 index 00000000..91d17eb2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1680 @@ -0,0 +1,103 @@ + +qemu-system-x86_64: ../softmmu/memory.c:1111: memory_region_transaction_commit: Assertion `qemu_mutex_iothread_locked()' failed. +Description of problem: +While testing master build, I have the following crash on shutdown of the VM: +qemu-system-x86_64: ../softmmu/memory.c:1111: memory_region_transaction_commit: Assertion `qemu_mutex_iothread_locked()' failed. +Steps to reproduce: +1. Run VM +2. Once booted, do poweroff inside the Linux VM +3. When poweroff completes, qemu crashes. +Additional information: +```(gdb) bt full +#0 0x00007ffff29edacf in raise () at /lib64/libc.so.6 +#1 0x00007ffff29c0ea5 in abort () at /lib64/libc.so.6 +#2 0x00007ffff29c0d79 in _nl_load_domain.cold.0 () at /lib64/libc.so.6 +#3 0x00007ffff29e6426 in () at /lib64/libc.so.6 +#4 0x0000555555bed6d3 in memory_region_transaction_commit () at ../softmmu/memory.c:1111 + as = <optimized out> + __PRETTY_FUNCTION__ = "memory_region_transaction_commit" +#5 0x0000555555bef2bf in memory_region_add_eventfd (mr=mr@entry=0x555557c318a0, addr=<optimized out>, size=size@entry=0, match_data=<optimized out>, data=<optimized out>, e=<optimized out>) at ../softmmu/memory.c:2583 + mrfd = {addr = {start = 0, size = 0}, match_data = false, data = 0, e = 0x555557c41aa4} + i = <optimized out> +#6 0x0000555555a2c85c in virtio_pci_ioeventfd_assign (d=0x555557c30a00, notifier=0x555557c41aa4, n=0, assign=<optimized out>) at ../hw/virtio/virtio-pci.c:347 + proxy = 0x555557c30a00 + vdev = <optimized out> + vq = <optimized out> + legacy = true + modern = <optimized out> + fast_mmio = true + modern_pio = false + modern_mr = <optimized out> + modern_notify_mr = 0x555557c319c0 + legacy_mr = 0x555557c31430 + modern_addr = <optimized out> +#7 0x0000555555a2be78 in virtio_bus_set_host_notifier (bus=0x555557c38d50, n=n@entry=0, assign=assign@entry=true) at ../hw/virtio/virtio-bus.c:296 + vdev = <optimized out> + k = 0x555556a7b620 + proxy = 0x555557c30a00 + vq = 0x555557c41a30 + notifier = 0x555557c41aa4 + r = <optimized out> + __func__ = "virtio_bus_set_host_notifier" +#8 0x0000555555ba1595 in virtio_scsi_set_host_notifier (s=s@entry=0x555557c38dd0, n=n@entry=0, vq=<optimized out>) at /root/qemu/include/hw/virtio/virtio-bus.h:35 + qbus = <optimized out> + rc = <optimized out> +#9 0x0000555555ba1860 in virtio_scsi_dataplane_start (vdev=<optimized out>) at ../hw/scsi/virtio-scsi-dataplane.c:130 + i = <optimized out> + rc = <optimized out> + vq_init_count = 0 + qbus = 0x555557c38d50 + k = 0x555556a7b620 + vs = 0x555557c38dd0 + s = 0x555557c38dd0 +#10 0x0000555555a2bbd2 in virtio_bus_start_ioeventfd (bus=0x555557c38d50) at ../hw/virtio/virtio-bus.c:236 + k = <optimized out> + proxy = 0x555557c30a00 + vdev = 0x555557c38dd0 + vdc = 0x555556a19cc0 + r = <optimized out> + __func__ = "virtio_bus_start_ioeventfd" +#11 0x0000555555bc0739 in virtio_device_start_ioeventfd (vdev=vdev@entry=0x555557c38dd0) at ../hw/virtio/virtio.c:3741 + qbus = <optimized out> + vbus = <optimized out> +#12 0x0000555555b9fc80 in virtio_scsi_defer_to_dataplane (s=0x555557c38dd0) at ../hw/scsi/virtio-scsi.c:614 + s = 0x555557c38dd0 +#13 0x0000555555b9fc80 in virtio_scsi_defer_to_dataplane (s=0x555557c38dd0) at ../hw/scsi/virtio-scsi.c:608 + s = 0x555557c38dd0 +#14 0x0000555555b9fc80 in virtio_scsi_handle_event (vdev=<optimized out>, vq=<optimized out>) at ../hw/scsi/virtio-scsi.c:1011 + s = 0x555557c38dd0 +#15 0x0000555555bba2af in virtio_queue_notify_vq (vq=0x555557c41ac8) at ../hw/virtio/virtio.c:2248 + vdev = 0x555557c38dd0 +#16 0x0000555555de7b08 in aio_dispatch_handler (ctx=ctx@entry=0x555556c2c130, node=0x555557ffbff0) at ../util/aio-posix.c:356 + progress = false + poll_ready = true + revents = <optimized out> +#17 0x0000555555de861c in aio_dispatch_ready_handlers (ready_list=0x7fffde952fe8, ctx=0x555556c2c130) at ../util/aio-posix.c:401 + progress = false + node = <optimized out> + ready_list = {lh_first = 0x0} + progress = true + use_notify_me = <optimized out> + timeout = <optimized out> + start = <optimized out> + __PRETTY_FUNCTION__ = "aio_poll" +#18 0x0000555555de861c in aio_poll (ctx=0x555556c2c130, blocking=blocking@entry=true) at ../util/aio-posix.c:723 + ready_list = {lh_first = 0x0} + progress = true + use_notify_me = <optimized out> + timeout = <optimized out> + start = <optimized out> + __PRETTY_FUNCTION__ = "aio_poll" +#19 0x0000555555ca9ae6 in iothread_run (opaque=opaque@entry=0x555556943200) at ../iothread.c:63 + iothread = 0x555556943200 +#20 0x0000555555deaf6a in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 + __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {93825016192880, 1094026140696841148, 140737488341294, 140737488341295, 140737488341440, 140736927707584, 6520036150746942396, 1094028099712322492}, __mask_was_saved = 0}}, __pad = {0x7fffde953110, 0x0, 0x0, 0x0}} + __cancel_routine = 0x555555deafc0 <qemu_thread_atexit_notify> + __not_first_call = <optimized out> + qemu_thread_args = <optimized out> + start_routine = 0x555555ca9aa0 <iothread_run> + arg = 0x555556943200 + r = <optimized out> +#21 0x00007ffff2d6c1ca in start_thread () at /lib64/libpthread.so.0 +#22 0x00007ffff29d8e73 in clone () at /lib64/libc.so.6 +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1687569 b/results/classifier/gemma3:12b/hypervisor/1687569 new file mode 100644 index 00000000..331a3a6d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1687569 @@ -0,0 +1,58 @@ + +when migration cancel, qemu main thread hung + +qemu version:v2.9.0-rc5 release + +1.virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 --copy-storage-all qemu+ssh://10.59.163.38/system +2.press Ctrl+C cancel migrate + + qemu main thread hung + +(gdb) bt +#0 0x00007fca9f4574b7 in ppoll () from /lib64/libc.so.6 +#1 0x0000000000944970 in qemu_poll_ns (fds=0x293e6e0, nfds=1, timeout=-1) at util/qemu-timer.c:322 +#2 0x0000000000947e16 in aio_poll (ctx=0x291d4b0, blocking=true) at util/aio-posix.c:622 +#3 0x00000000008b6094 in nbd_teardown_connection (bs=0x29ccdc0) at block/nbd-client.c:59 +#4 0x00000000008b6df1 in nbd_client_close (bs=0x29ccdc0) at block/nbd-client.c:377 +#5 0x00000000008b5988 in nbd_close (bs=0x29ccdc0) at block/nbd.c:488 +#6 0x00000000008435de in bdrv_close (bs=0x29ccdc0) at block.c:2919 +#7 0x0000000000843c86 in bdrv_delete (bs=0x29ccdc0) at block.c:3100 +#8 0x000000000084620b in bdrv_unref (bs=0x29ccdc0) at block.c:4087 +#9 0x00000000008411d1 in bdrv_root_unref_child (child=0x30e4800) at block.c:1891 +#10 0x000000000084128a in bdrv_unref_child (parent=0x29c0660, child=0x30e4800) at block.c:1915 +#11 0x000000000084362a in bdrv_close (bs=0x29c0660) at block.c:2925 +#12 0x0000000000843c86 in bdrv_delete (bs=0x29c0660) at block.c:3100 +#13 0x000000000084620b in bdrv_unref (bs=0x29c0660) at block.c:4087 +#14 0x00000000008411d1 in bdrv_root_unref_child (child=0x3013910) at block.c:1891 +#15 0x0000000000848149 in block_job_remove_all_bdrv (job=0x3fa7800) at blockjob.c:154 +#16 0x00000000008a8dd8 in mirror_exit (job=0x3fa7800, opaque=0x7fca90000bf0) at block/mirror.c:576 +#17 0x0000000000849e22 in block_job_defer_to_main_loop_bh (opaque=0x7fca90000d90) at blockjob.c:794 +#18 0x00000000009420c4 in aio_bh_call (bh=0x7fca90000dc0) at util/async.c:90 +#19 0x000000000094216f in aio_bh_poll (ctx=0x291d4b0) at util/async.c:118 +#20 0x00000000009480d9 in aio_poll (ctx=0x291d4b0, blocking=true) at util/aio-posix.c:682 +#21 0x00000000008b6094 in nbd_teardown_connection (bs=0x2921350) at block/nbd-client.c:59 +#22 0x00000000008b6df1 in nbd_client_close (bs=0x2921350) at block/nbd-client.c:377 +#23 0x00000000008b5988 in nbd_close (bs=0x2921350) at block/nbd.c:488 +#24 0x00000000008435de in bdrv_close (bs=0x2921350) at block.c:2919 +#25 0x0000000000843c86 in bdrv_delete (bs=0x2921350) at block.c:3100 +#26 0x000000000084620b in bdrv_unref (bs=0x2921350) at block.c:4087 +#27 0x00000000008411d1 in bdrv_root_unref_child (child=0x390d180) at block.c:1891 +#28 0x000000000084128a in bdrv_unref_child (parent=0x4eba200, child=0x390d180) at block.c:1915 +#29 0x000000000084362a in bdrv_close (bs=0x4eba200) at block.c:2925 +#30 0x0000000000843c86 in bdrv_delete (bs=0x4eba200) at block.c:3100 +#31 0x000000000084620b in bdrv_unref (bs=0x4eba200) at block.c:4087 +#32 0x00000000008411d1 in bdrv_root_unref_child (child=0x4ebf990) at block.c:1891 +#33 0x0000000000848149 in block_job_remove_all_bdrv (job=0x4ea85b0) at blockjob.c:154 +#34 0x00000000008a8dd8 in mirror_exit (job=0x4ea85b0, opaque=0x7fca98000bf0) at block/mirror.c:576 +#35 0x0000000000849e22 in block_job_defer_to_main_loop_bh (opaque=0x7fca980013d0) at blockjob.c:794 +#36 0x00000000009420c4 in aio_bh_call (bh=0x7fca9801e0c0) at util/async.c:90 +#37 0x000000000094216f in aio_bh_poll (ctx=0x291d4b0) at util/async.c:118 +---Type <return> to continue, or q <return> to quit--- +#38 0x00000000009476ae in aio_dispatch (ctx=0x291d4b0) at util/aio-posix.c:429 +#39 0x00000000009425e4 in aio_ctx_dispatch (source=0x291d4b0, callback=0, user_data=0x0) at util/async.c:261 +#40 0x00007fcaa0101f0e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#41 0x0000000000945d86 in glib_pollfds_poll () at util/main-loop.c:213 +#42 0x0000000000945ea7 in os_host_main_loop_wait (timeout=124777230) at util/main-loop.c:261 +#43 0x0000000000945f72 in main_loop_wait (nonblocking=0) at util/main-loop.c:517 +#44 0x00000000005c7794 in main_loop () at vl.c:1898 +#45 0x00000000005cec57 in main (argc=64, argv=0x7fffe7020c58, envp=0x7fffe7020e60) at vl.c:4709 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1687578 b/results/classifier/gemma3:12b/hypervisor/1687578 new file mode 100644 index 00000000..b986b1a6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1687578 @@ -0,0 +1,15 @@ + +when migrate vm, reboot in guest os, the guest os sometime hang + +qemu version:v2.9.0-rc5 release + +1.virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 --copy-storage-inc qemu+ssh://10.59.163.38/system +2.run reboot in guest os, add reboot in /etc/rc.local +3.guest os hang sometime. + +strace output of qemu: + +ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, {0, 698000000}, NULL, 8) = 0 (Timeout) +poll([{fd=20, events=POLLOUT}], 1, 0) = 1 ([{fd=20, revents=POLLOUT|POLLHUP}]) +ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, {0, 999000000}, NULL, 8^C <unfinished ...> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1693649 b/results/classifier/gemma3:12b/hypervisor/1693649 new file mode 100644 index 00000000..9988e1ec --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1693649 @@ -0,0 +1,12 @@ + +x86 pause misbehaves with -cpu haswell + +Using qemu-2.9.0 + +When booting NetBSD using '-cpu haswell -smp 4', the system fails to initialize the additional CPUs. It appears as though the "application processor" enters routine x86_pause() but never returns. + +x86_pause() is simply two assembler instructions: 'pause; ret;' + +Replacing the routine with 'nop; nop; ret;' allows the system to proceed, of course without the benefit of the pause instruction on spin-loops! + +Additionally, booting with '-cpu phenom -smp 4' also works, although the system does seem confused about the type of CPU being used. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1694 b/results/classifier/gemma3:12b/hypervisor/1694 new file mode 100644 index 00000000..ebb6b2aa --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1694 @@ -0,0 +1,2 @@ + +cpu-x86-uarch-abi.py is missing "xsave" cpuid for x86-64-v3 && x86-64-v4 diff --git a/results/classifier/gemma3:12b/hypervisor/1696353 b/results/classifier/gemma3:12b/hypervisor/1696353 new file mode 100644 index 00000000..c5609e1a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1696353 @@ -0,0 +1,36 @@ + +golang binaries fail to start under linux-user + +With current master golang binaries fail when run under linux-user, for example: + +[will@localhost qemu]$ ./arm-linux-user/qemu-arm glide +runtime: failed to create new OS thread (have 2 already; errno=22) +fatal error: newosproc + +runtime stack: +runtime.throw(0x45f879, 0x9) + /usr/lib/golang/src/runtime/panic.go:566 +0x78 +runtime.newosproc(0x1092c000, 0x1093bfe0) + /usr/lib/golang/src/runtime/os_linux.go:160 +0x1b0 +runtime.newm(0x4ae1e8, 0x0) + /usr/lib/golang/src/runtime/proc.go:1572 +0x12c +runtime.main.func1() + /usr/lib/golang/src/runtime/proc.go:126 +0x24 +runtime.systemstack(0x5ef900) + /usr/lib/golang/src/runtime/asm_arm.s:247 +0x80 +runtime.mstart() + /usr/lib/golang/src/runtime/proc.go:1079 + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/lib/golang/src/runtime/asm_arm.s:192 +0x4 fp=0x109287ac sp=0x109287a8 +runtime.main() + /usr/lib/golang/src/runtime/proc.go:127 +0x5c fp=0x109287d4 sp=0x109287ac +runtime.goexit() + /usr/lib/golang/src/runtime/asm_arm.s:998 +0x4 fp=0x109287d4 sp=0x109287d4 + +The reason for this is that the golang runtime does not pass the CLONE_SYSVMEM flag to clone so the clone flags checks fail: + +https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L155 + +The attached patch allows golang binaries to start under linux-user. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1699867 b/results/classifier/gemma3:12b/hypervisor/1699867 new file mode 100644 index 00000000..5d29985b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1699867 @@ -0,0 +1,22 @@ + +x86_64 qemu crashes at far call into long-mode + +I am experimenting with this OS https://github.com/phil-opp/blog_os and spotted a weird behavior with qemu. + +I am looking at code that does transition from 32bit mode to 64bit mode. Right now it does 'jmp $SELECTOR,64bitfunction'. https://github.com/phil-opp/blog_os/blob/557c6a58ea11e31685b9d014d307002d64df5c22/src/arch/x86_64/boot.asm#L32 + +This code works fine with qemu/kvm/vmware. + +To transition from 32 to 64 bit code it is possible to use 'call' operation. So I am trying to replace that code with 'call $SELECTOR,64bitfunction'. It works fine with kvm and wmware. But it fails with Qemu emulation. See the interrup debug log attached. qemu crashes at 10302c (far call mnemonic). + + + 103016: e8 18 00 00 00 callq 103033 <set_up_page_tables> + 10301b: e8 5c 00 00 00 callq 10307c <enable_paging> + 103020: e8 ec 00 00 00 callq 103111 <set_up_SSE> + 103025: 0f 01 15 28 00 10 00 lgdt 0x100028(%rip) # 203054 <GCC_except_table2+0xdb5f8> + 10302c: 9a (bad) + 10302d: 40 31 10 rex xor %edx,(%rax) + 103030: 00 08 add %cl,(%rax) + + +As the code works at hardware I expect it to work with qemu. Thus current qemu behavior looks like a bug. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1701835 b/results/classifier/gemma3:12b/hypervisor/1701835 new file mode 100644 index 00000000..9370e6a5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1701835 @@ -0,0 +1,168 @@ + +floating-point operation bugs in qemu-alpha + +When running the gnulib testsuite, I'm seeing test failures in the tests for libm functions + cbrt + cbrtf + ceil + ceilf + coshf + exp2 + exp2f + floor + floorf + fma + fmaf + fmal + frexp + frexpf + hypot + hypotf + hypotl + ilogb + ilogbf + isfinite + isinf + isnan + isnand + isnanf + ldexp + ldexpf + ldexpl + log1p + log1pf + log2 + log2f + logb + logbf + logbl + rint + rintf + rintl + signbit + sqrt + sqrtf + strtod +that I don't see when running the same (statically linked) executables in a VM, through qemu-system-alpha. + +How to reproduce: +- Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math --single-configure cbrt cbrtf ceil ceilf coshf exp2 exp2f float floor floorf fma fmaf fmal frexp frexpf hypot hypotf hypotl ilogb ilogbf isfinite isinf isnan isnand isnanf ldexp ldexpf ldexpl log1p log1pf log2 log2f logb logbf logbl math printf-frexp rint rintf rintl round roundf signbit sqrt sqrtf strtod trunc truncf +- Copy the resulting directory to a VM running Linux 2.6.26 with qemu-system-alpha. +- There, configure and build the package: + mkdir build-native-static; cd build-native-static; ../configure CPPFLAGS="-Wall" LDFLAGS="-static"; make; make check + Only 4 tests fail. +- Copy the resulting binaries back to the original x86_64 machine. +- Set environment variables for using qemu-alpha. +- Here, 50 tests fail that did not fail originally: + +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-cbrt +../../gltests/test-cbrt.h:39: assertion 'err > - L_(4.0) * L_(16.0) / TWO_MANT_DIG && err < L_(4.0) * L_(16.0) / TWO_MANT_DIG' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-coshf +../../gltests/test-coshf.c:37: assertion 'y >= 1.1854652f && y <= 1.1854653f' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-float +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma2 +../../gltests/test-fma2.h:116: assertion 'result == expected' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf2 +../../gltests/test-fma2.h:116: assertion 'result == expected' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmal2 +../../gltests/test-fma2.h:116: assertion 'result == expected' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexp +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexpf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypot +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotl +../../gltests/test-hypot.h:41: assertion 'z == HUGEVAL' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogb +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogbf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isfinite +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isinf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnan +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand-nolibm +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnanf-nolibm +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnanf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ldexp +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ldexpf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ldexpl +../../gltests/test-ldexp.h:99: assertion 'y == expected' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-log1p +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-log1pf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-log2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-log2f +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-logb +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-logbf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-math +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-printf-frexp +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-rint +../../gltests/test-rint.c:63: assertion 'rint (0.7) == 1.0' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-rintf +../../gltests/test-rintf.c:63: assertion 'rintf (0.7f) == 1.0f' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-rintl +../../gltests/test-rintl.c:68: assertion 'rintl (0.7L) == 1.0L' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-round1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-roundf1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-signbit +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-sqrt +../../gltests/test-sqrt.h:40: assertion 'err > - L_(16.0) / TWO_MANT_DIG && err < L_(16.0) / TWO_MANT_DIG' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-trunc1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-truncf1 +Floating point exception (core dumped) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1702 b/results/classifier/gemma3:12b/hypervisor/1702 new file mode 100644 index 00000000..8ec0dfd9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1702 @@ -0,0 +1,9 @@ + +Enable whpx acceleration, unable to start Linux system +Description of problem: +The accel=whpx parameter stops responding in the boot menu. + +The accel=whpx,kernel-irqchip=off parameter stops responding during startup +Additional information: + + diff --git a/results/classifier/gemma3:12b/hypervisor/1705 b/results/classifier/gemma3:12b/hypervisor/1705 new file mode 100644 index 00000000..440931b0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1705 @@ -0,0 +1,67 @@ + +Illegal instruction when I want to numactl --cpubind=0 --membind=1 to CXL Memory +Description of problem: +I ran QEMU for simulating CXL DRAM and when I tried to run `numactl --cpubind=0 --membind=1 ls` , I got `Illegal instruction` +The numa node 1 was the CXL DRAM simulated by QEMU. + +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 free: 31325 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 + +When I ran on numa node 1, no failed + +> root@8003:~# numactl --membind=0 ls +> ndctl + +When I ran on numa node 1(CXL DRAM),it failed. + +> root@8003:~# numactl --membind=1 ls +> [ 913.975032] traps: ls[667] trap invalid opcode ip:7fdec255d180 sp:7ffd3c507288 error:0 in ld-linux-x86-64.so.2[7fdec2546000+2a000] +> **Illegal instruction** +Steps to reproduce: +1. start the guest +2. cxl list (we could see the simulated CXL DRAM) +> root@8003:~# cxl list +> [ +> { +> "memdev":"mem0", +> "ram_size":34359738368, +> "serial":0, +> "host":"0000:0d:00.0" +> } +> ] +3. cxl create-region -t ram -d decoder0.0 -m mem0 +4. daxctl reconfigure-device dax0.0 --mode=system-ram +5. numactl -H +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 fr +> ee: 31254 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 +6. numactl --membind=1 ls +> root@8003:~# numactl --membind=1 ls +> [38441.892140] **traps: ls[861] trap invalid opcode ip:7f15db6ac180 sp:7ffc648755c8 **error:0 in ld-linux-x86-64.so.2[7f15db695000+2a000] +> **Illegal instruction** +Additional information: +When I run dmesg, I found an error. +> root@8003:~# dmesg|grep error +> [ 2.321130] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 + +Since my CPU is a Xeon III, not a Xeon IV with CXL support, **I'm wondering if it's because the CPU doesn't support CXL instructions, or if the Xeon III can emulate it, just because my settings don't make sense**. If this is my settings problem, could you help me to deal this? Or it just caused by my Xeon III,I will update it to Xeon IV. diff --git a/results/classifier/gemma3:12b/hypervisor/1708 b/results/classifier/gemma3:12b/hypervisor/1708 new file mode 100644 index 00000000..24c7c712 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1708 @@ -0,0 +1,68 @@ + +RISCV: Illegal instruction delegated to VS mode sets the wrong vscause value +Description of problem: +When delegating an illegal instruction exception caused in VS-mode to VS-mode, the vscause value for an illegal instruction is set incorrectly. + +Steps to reproduce: +1. Delegate 2(,6,10) in medeleg and hedeleg. +2. Enter VS-mode +3. Cause an illegal instruction fault, cause 6 can't happen in QEMU since there is misaligned support and 10 can't be delegated to VS mode. +4. The (v)scause CSR is then set to 1, i.e. instruction access fault which isn't correct. + +I have located the issue in the code @ cpu_helper.c:1703 +``` +if ((cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT || + cause == IRQ_VS_EXT)) { + cause = cause - 1; +} +``` + +The if statement should include a check for the async otherwise the cause shouldn't be altered. The patch I propose is simply to **and** the current statement with async. +``` +if (async & (cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT || + cause == IRQ_VS_EXT)) { + cause = cause - 1; +} +``` +Additional information: +Log where the incorrect cause is set. Note this line: `DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0` +``` +TRACE: [src/hart_ctrl.c:35] STARTING CPU 0 +TRACE: [src/page_tables.c:343] Setting up page tables between 0x80000000 -> 0x81c00000 +TRACE: [src/page_tables.c:359] Setting up page tables between 0x81c01000 -> 0x81c02000 +TRACE: [src/page_tables.c:374] Setting up page tables for UART 0x10000000 +TRACE: [src/page_tables.c:386] Setting up page tables for CLINT 0x2000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x24000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28001000 +TRACE: [src/main.c:32] STARTING HYPERVISOR TESTS +DEBUG: [src/util_fn.c:1175] pmpcfg0 = 0x00000000000f000f +DEBUG: [src/util_fn.c:1176] pmpcfg2 = 0x0000000000000000 +PMP Entry : 0 +Low Address : 0x0 +High Address : 0x81c00000 +Address Range : 0x0 - 0x81c00000 +Mode : TOR +Executable : Yes +Writable : Yes +Readable : Yes +Locked : No +-------------------------------------- +PMP Entry : 2 +Low Address : 0x82000000 +High Address : 0xfffffffffffffffc +Address Range : 0x82000000 - 0xfffffffffffffffc +Mode : TOR +Executable : Yes +Writable : Yes +Readable : Yes +Locked : No +-------------------------------------- +DEBUG: [src/trap_trigger.c: 85] Switching mode to VS +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x00000000800062a4, tval:0x0000000000000000, desc=illegal_instruction +DEBUG: [src/trap_handling.c: 102] Illegal instruction exception: MEPC = 0x800062a4, MTVAL = 0x0 +TRACE: [src/util_fn.c:374] Done switching mode +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x0000000080008850, tval:0x0000000000000000, desc=illegal_instruction +DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0 +ERROR: [src/trap_handling.c:158] The following assert failed: mask_cause == cause2check +mask_cause = 0x1 diff --git a/results/classifier/gemma3:12b/hypervisor/1709025 b/results/classifier/gemma3:12b/hypervisor/1709025 new file mode 100644 index 00000000..e08489b5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1709025 @@ -0,0 +1,40 @@ + +Disk corrupted after snapshot deletion + + I found the vm disk corruption after snapshot deletion sometimes(the probability is very low, I'm afraid i can't reproduce it). And I found there is a patch for it as follow, but I'm not sure whether the patch repaired the bug. + Drain disk before snapshot deletion can't guarantee anything, there is still pending IO in snapshot-deletion process. Anyone can help? + +author Zhang Haoyu <email address hidden> 2014-10-21 16:38:01 +0800 +committer Stefan Hajnoczi <email address hidden> 2014-11-03 09:48:42 +0000 +commit 3432a1929ee18e08787ce35476abd74f2c93a17c (patch) +tree 13a81c0a46707d91622f1593ccf7b926935371fd /block/snapshot.c +parent 573742a5431a99ceaba6968ae269cee247727cce (diff) +snapshot: add bdrv_drain_all() to bdrv_snapshot_delete() to avoid concurrency problem +If there are still pending i/o while deleting snapshot, +because deleting snapshot is done in non-coroutine context, and +the pending i/o read/write (bdrv_co_do_rw) is done in coroutine context, +so it's possible to cause concurrency problem between above two operations. +Add bdrv_drain_all() to bdrv_snapshot_delete() to avoid this problem. + +Signed-off-by: Zhang Haoyu <email address hidden> +Reviewed-by: Paolo Bonzini <email address hidden> +Message-id: <email address hidden> +Signed-off-by: Stefan Hajnoczi <email address hidden> +Diffstat (limited to 'block/snapshot.c') +-rw-r--r-- block/snapshot.c 4 +1 files changed, 4 insertions, 0 deletions +diff --git a/block/snapshot.c b/block/snapshot.c +index 85c52ff..698e1a1 100644 +--- a/block/snapshot.c ++++ b/block/snapshot.c +@@ -236,6 +236,10 @@ int bdrv_snapshot_delete(BlockDriverState *bs, + error_setg(errp, "snapshot_id and name are both NULL"); + return -EINVAL; + } ++ ++ /* drain all pending i/o before deleting snapshot */ ++ bdrv_drain_all(); ++ + if (drv->bdrv_snapshot_delete) { + return drv->bdrv_snapshot_delete(bs, snapshot_id, name, errp); + } \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1712564 b/results/classifier/gemma3:12b/hypervisor/1712564 new file mode 100644 index 00000000..aa86d8ff --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1712564 @@ -0,0 +1,26 @@ + +loadvm fails twice in sequence + +13:38:23) shorne_: Hello, I was doing some testing with migrations for my OpenRISC SMP patch set, I noticed something that looks like a bug, wondering if someone else wants to confirm +(13:38:47) shorne_: Basically, calling loadvm 2 times causes crash +(13:38:54) shorne_: migration/savevm.c: qemu_event_set(&mis->main_thread_load_event) +(13:38:54) stefanha: fam: Here is my take at this change: https://paste.debian.net/982690/ +(13:38:56) shorne_: assert(ev->initialized) - fails inside +(13:39:32) stefanha: quintela davidgiluk: ^ +(13:41:23) ***davidgiluk looks +(13:41:40) shorne_: c096358e747 util/qemu-thread-posix.c (Fam Zheng 2017-07-04 20:23:25 +0800 397) assert(ev->initialized); +(13:41:51) davidgiluk: shorne_: So you're doing a loadvm to load a snapshot and then again? +(13:42:02) shorne_: Looks like adding that assert() was done really recently +(13:42:41) shorne_: yes, just loadvm 'a' ... then wait a bit longer, loadvm 'a' again (confirm clocks go back etc) +(13:42:50) stefanha: fam: While you're having dinner I'll work on turning my script into a qemu-iotests test case that we can merge. +(13:44:03) gpiccoli [~gpiccoli@0002093a.user.oftc.net] entered the room. +(13:44:21) davidgiluk: shorne_: Well, it looks like the c09635 assert is a sanity check to make sure we didn't do anything stupid, and well..... +(13:44:57) pm215: migration_incoming_get_current() and migration_incoming_state_destroy() seem a bit mismatched +(13:45:13) davidgiluk: pm215: Yep +(13:45:46) davidgiluk: pm215: Generally we've thought that an incoming migration normally only happens once - shorne_'s case is the exception +(13:46:03) shorne_: pm215: yeah, it looked something like that I just had a few seconds to look at today +(13:46:03) HariharanTS left the room (quit: Ping timeout: 480 seconds). +(13:46:03) shorne_ is now known as shorne +(13:48:05) shorne: davidgiluk: pm215: thanks for having a look. Unfortunately I need to head off to bed and put kids to sleep +(13:49:11) davidgiluk: shorne: Sleep well, no nightmares about event destroyers.... +(13:49:30) davidgiluk: pm215: Yeh this is fall out from b4b076daf32 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1713408 b/results/classifier/gemma3:12b/hypervisor/1713408 new file mode 100644 index 00000000..0cef5b0d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1713408 @@ -0,0 +1,70 @@ + +qemu crashes with "GLib-ERROR **: gmem.c" error when a negative value passed to "maxcpus" + +# ppc64-softmmu/qemu-system-ppc64 --nographic -vga none -machine pseries,accel=kvm,kvm-type=HV -m size=20g -device virtio-blk-pci,drive=rootdisk -drive file=/home/nasastry/avocado-fvt-wrapper/data/avocado-vt/images/pegas-1.0-ppc64le.qcow2,if=none,cache=none,id=rootdisk,format=qcow2 -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -device nec-usb-xhci -smp 8,cores=1,threads=1,maxcpus=-12 + +(process:12149): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes + +From GDB: +[New Thread 0x3fffb5aceb60 (LWP 12190)] + +(process:12184): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes + +Program received signal SIGTRAP, Trace/breakpoint trap. +0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +Missing separate debuginfos, use: debuginfo-install glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libgcc-4.8.5-16.el7.ppc64le libstdc++-4.8.5-16.el7.ppc64le ncurses-libs-5.9-13.20130511.el7.ppc64le nss-3.28.4-8.el7.ppc64le nss-softokn-freebl-3.28.3-6.el7.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le +(gdb) bt +#0 0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +#1 0x00003fffb796be9c in _g_log_abort () from /lib64/libglib-2.0.so.0 +#2 0x00003fffb796d4c4 in g_log_default_handler () from /lib64/libglib-2.0.so.0 +#3 0x00003fffb796d86c in g_logv () from /lib64/libglib-2.0.so.0 +#4 0x00003fffb796db00 in g_log () from /lib64/libglib-2.0.so.0 +#5 0x00003fffb796b694 in g_malloc0 () from /lib64/libglib-2.0.so.0 +#6 0x000000001018fa84 in spapr_possible_cpu_arch_ids (machine=0x11165660) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:3322 +#7 0x000000001018b444 in spapr_init_cpus (spapr=0x11165660) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2096 +#8 0x000000001018bc6c in ppc_spapr_init (machine=0x11165660) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2275 +#9 0x000000001041ca38 in machine_run_board_init (machine=0x11165660) at hw/core/machine.c:760 +#10 0x000000001037723c in main (argc=24, argv=0x3ffffffff108, envp=0x3ffffffff1d0) at vl.c:4633 +(gdb) i r +r0 0xfa 250 +r1 0x3fffffffe450 70368744170576 +r2 0x3fffb7608100 70367525765376 +r3 0x0 0 +r4 0x2f98 12184 +r5 0x5 5 +r6 0x0 0 +r7 0x3fffa8000020 70367267782688 +r8 0x2f98 12184 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +r13 0x3fffb64fccb0 70367507893424 +r14 0x0 0 +r15 0x0 0 +r16 0x0 0 +r17 0x0 0 +r18 0x1 1 +r19 0x0 0 +r20 0x3fffb796d3f0 70367529325552 +r21 0x0 0 +r22 0x20000000 536870912 +r23 0x1 1 +r24 0x3fffb7a61498 70367530325144 +r25 0x3fffb7a614e8 70367530325224 +r26 0x3fffb7a61488 70367530325128 +r27 0x3fffa80008c0 70367267784896 +r28 0x3fffb79cd2a8 70367529718440 +r29 0x3fffb79cd2a8 70367529718440 +r30 0xffffffffffffffff 18446744073709551615 +r31 0x1 1 +pc 0x3fffb75e5408 0x3fffb75e5408 <raise+56> +msr 0x900000000000d033 10376293541461676083 +cr 0x42244842 1109674050 +lr 0x3fffb796be9c 0x3fffb796be9c <_g_log_abort+60> +ctr 0x0 0 +xer 0x0 0 +orig_r3 0x2f98 12184 +trap 0xc00 3072 + +Similar error observed on x86_64 and PPC64LE architectures. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1715573 b/results/classifier/gemma3:12b/hypervisor/1715573 new file mode 100644 index 00000000..a678c9fe --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1715573 @@ -0,0 +1,8 @@ + +Android-x86_64 guest - "Could not disable RealTimeClock events (20160831/evxfevnt-267)"; UI sluggish, ACPI doesn't work with QEMU 2.10.0 + +I'm running a custom-built Android-x86_64 guest in an Arch Linux host with the 4.12.10 kernel. + +Following the latest Arch Linux upgrade to QEMU 2.10.0-1, upon booting the virtual machine, I get the error mentioned in the title. Afterwards, the virtual machine becomes slower and slower. The ACPI functions (the libvirt's Shutdown button, for example) don't work. + +When I downgrade to QEMU 2.9.0-3 everything works fine once again. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1719984 b/results/classifier/gemma3:12b/hypervisor/1719984 new file mode 100644 index 00000000..2bf9ca2b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1719984 @@ -0,0 +1,7 @@ + +wrgsbase misemulated in x86_64-softmmu + +qemu revision: cfe4cade054c0e0d00d0185cdc433a9e3ce3e2e4 +command: ./qemu-system-x86_64 -m 2048 -nographic -net none -smp 4,threads=2 -machine q35 -kernel zircon.bin -cpu Haswell,+smap,-check -initrd bootdata.bin -append 'TERM=screen kernel.halt-on-panic=true ' + +On this revision, the VM reports CPUID.07H.0H.EBX[0] = 1. In this VM, with CR4[16] set to 1, wrgsbase triggers #UD, which mismatches the behavior described in Intel's instruction reference. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1721 b/results/classifier/gemma3:12b/hypervisor/1721 new file mode 100644 index 00000000..7542fff7 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1721 @@ -0,0 +1,63 @@ + +Problem in combination with RabbitMQ and erlang +Description of problem: +I have a problem with rabbitMQ /erlang / Qemu on my local system. + +I use docker with: + +version: "3.6" +``` +services: + rabbitmq: + image: rabbitmq:3-management +``` + +Docker Desktop 4.20.1 (110738) +Docker version 24.0.2, build cb74dfc + +Apple Macbook Pro with M1 Chip Ventura 13.4. + +I deleted all containers and images related to rabbitMQ. Then when I do a: docker compose up -d + +I always get this error and rabbitMQ stopps: + +``` +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:18.984151+00:00 [notice] <0.44.0> Application mnesia exited with reason: stopped +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.658039+00:00 [info] <0.230.0> Waiting for Mnesia tables for 30000 ms, 9 retries left +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.659274+00:00 [info] <0.230.0> Successfully synced tables from a peer +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.662647+00:00 [notice] <0.283.0> Feature flags: attempt to enable `stream_sac_coordinator_unblock_group`... +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.793670+00:00 [notice] <0.283.0> Feature flags: `stream_sac_coordinator_unblock_group` enabled +rabbitmq-server-rabbitmq-1 | qemu: uncaught target signal 11 (Segmentation fault) - core dumped +rabbitmq-server-rabbitmq-1 | Segmentation fault +``` + +In the past it worked, like 5 months ago. + +Reproduction steps docker compose up -d + +Expected behavior that the container runs and does not exit + +Additional context docker compose logs + +``` +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.946635+00:00 [notice] <0.44.0> Application syslog exited with reason: stopped +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.966134+00:00 [notice] <0.230.0> Logging: switching to configured handler(s); following messages may not be visible in this log output +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.973002+00:00 [notice] <0.230.0> Logging: configured log handlers are now ACTIVE +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539052+00:00 [info] <0.230.0> ra: starting system quorum_queues +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539748+00:00 [info] <0.230.0> starting Ra system: quorum_queues in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/quorum/rabbit@4fb71bcd203a +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.715984+00:00 [info] <0.261.0> ra system 'quorum_queues' running pre init for 0 registered servers +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.749375+00:00 [info] <0.262.0> ra: meta data store initialised for system quorum_queues. 0 record(s) recovered +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.786151+00:00 [notice] <0.267.0> WAL: ra_log_wal init, open tbls: ra_log_open_mem_tables, closed tbls: ra_log_closed_mem_tables +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857344+00:00 [info] <0.230.0> ra: starting system coordination +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857635+00:00 [info] <0.230.0> starting Ra system: coordination in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/coordination/rabbit@4fb71bcd203a +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.868808+00:00 [info] <0.274.0> ra system 'coordination' running pre init for 0 registered servers +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.874965+00:00 [info] <0.275.0> ra: meta data store initialised for system coordination. 0 record(s) recovered +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.875747+00:00 [notice] <0.280.0> WAL: ra_coordination_log_wal init, open tbls: ra_coordination_log_open_mem_tables, closed tbls: ra_coordination_log_closed_mem_tables +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Starting RabbitMQ 3.12.0 on Erlang 25.3.2.2 [jit] +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Copyright (c) 2007-2023 VMware, Inc. or its affiliates. +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Licensed under the MPL 2.0. Website: https://rabbitmq.com +rabbitmq-server-rabbitmq-1 | +rabbitmq-server-rabbitmq-1 | +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1721744 b/results/classifier/gemma3:12b/hypervisor/1721744 new file mode 100644 index 00000000..129c2265 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1721744 @@ -0,0 +1,53 @@ + +Help content missing for newly added machine properties + + +Help content missing for newly added machine properties, it would be needed by libvirt and other management layers to query to add support, Thanks. + +max-cpu-compat,vsmt,modern-hotplug-events,resize-hpt + +Steps: +1. Compile qemu @below commit +2. ./ppc64-softmmu/qemu-system-ppc64 -h +.... +-machine [type=]name[,prop[=value][,...]] + selects emulated machine ('-machine help' for list) + property accel=accel1[:accel2[:...]] selects accelerator + supported accelerators are kvm, xen, hax or tcg (default: tcg) + kernel_irqchip=on|off|split controls accelerated irqchip support (default=off) + vmport=on|off|auto controls emulation of vmport (default: auto) + kvm_shadow_mem=size of KVM shadow MMU in bytes + dump-guest-core=on|off include guest memory in a core dump (default=on) + mem-merge=on|off controls memory merge support (default: on) + igd-passthru=on|off controls IGD GFX passthrough support (default=off) + aes-key-wrap=on|off controls support for AES key wrapping (default=on) + dea-key-wrap=on|off controls support for DEA key wrapping (default=on) + suppress-vmdesc=on|off disables self-describing migration (default=off) + nvdimm=on|off controls NVDIMM support (default=off) + enforce-config-section=on|off enforce configuration section migration (default=off) + s390-squash-mcss=on|off controls support for squashing into default css (default=off) +.... + +===> Not showing help of mentioned properties. + + + +Verified at todays below commit +#git show +commit d8f932cc696250cb740240d668b39df5fbb2d5a0 +Merge: 67caeea 4504273 +Author: Peter Maydell <email address hidden> +Date: Thu Oct 5 16:54:29 2017 +0100 + + Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging + + # gpg: Signature made Thu 05 Oct 2017 15:25:21 BST + # gpg: using RSA key 0x9CA4ABB381AB73C8 + # gpg: Good signature from "Stefan Hajnoczi <email address hidden>" + # gpg: aka "Stefan Hajnoczi <email address hidden>" + # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 + + * remotes/stefanha/tags/tracing-pull-request: + checkpatch: fix incompatibility with old perl + + Signed-off-by: Peter Maydell <email address hidden> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1722074 b/results/classifier/gemma3:12b/hypervisor/1722074 new file mode 100644 index 00000000..f35932b8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1722074 @@ -0,0 +1,70 @@ + +warning: host doesn't support requested feature: CPUID.01H:ECX.vmx + +I encountered the bug today: + +warning: host doesn't support requested feature: CPUID.01H:ECX.vmx + +My Ubuntu have this version of QEMU installed: + +qemu-system-x86_64 --version + +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2003-2008 Fabrice Bellard + +And PC is a AMD Ryzen7 CPU built, and since it is not Intel CPU: + + +cat /proc/cpuinfo |more + +processor : 0 +vendor_id : AuthenticAMD +cpu family : 23 +model : 1 +model name : AMD Ryzen 7 1700X Eight-Core Processor +stepping : 1 +microcode : 0x800110e +cpu MHz : 2200.000 +cache size : 512 KB +physical id : 0 +siblings : 16 +core id : 0 +cpu cores : 8 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov +pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp + lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq +monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf +_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw s +kinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate +vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt +xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale v +mcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov +succor smca +bugs : fxsave_leak sysret_ss_attrs null_seg +bogomips : 6787.24 +TLB size : 2560 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm hwpstate eff_freq_ro [13] [14] + +processor : 1 +vendor_id : AuthenticAMD +cpu family : 23 +model : 1 +model name : AMD Ryzen 7 1700X Eight-Core Processor +stepping : 1 +microcode : 0x800110e +cpu MHz : 2200.000 +cache size : 512 KB + +From other places, it can be seen that this is an AMD CPU issue: + +https://www.virtualmin.com/node/52227 + +not sure? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1723488 b/results/classifier/gemma3:12b/hypervisor/1723488 new file mode 100644 index 00000000..f72ef01f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1723488 @@ -0,0 +1,38 @@ + +HAX on Windows, memory lease error + +Today I tried to use QEMU on Windows 8.1 x64 with Intel HAX. + +Command line: qemu-system-x86_64.exe -accel hax -m 8000 -hda /opt/disk/ubuntu.img -cdrom /opt/iso/ubuntu-17.04-server-amd64.iso + +Host machine has 32Gb physical memory, I got error: + +HAX is working and emulator runs in fast virt mode. +** +ERROR:A:/msys64/home/admin/git/qemu/target/i386/hax-mem.c:210:hax_process_section: assertion failed: (size <= UINT32_MAX) + +When using -m 4000 (and below) everything is fine. But if I try use >4000 and <8000 I get crash with errors: + +HAX is working and emulator runs in fast virt mode. +hax_transaction_commit: Failed mapping @0x0000000100000000+0x78800000 flags 00 +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1724570 b/results/classifier/gemma3:12b/hypervisor/1724570 new file mode 100644 index 00000000..a2da06f4 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1724570 @@ -0,0 +1,40 @@ + +qemu-system-x86_64 generates ACPI tables with broken endianess when run on big-endian hosts + +The bios-tables-test always fails when run on a big-endian host, which has iasl installed. When it calls iasl to dumps the AML files into ASL files, iasl complains + +Intel ACPI Component Architecture +ASL+ Optimizing Compiler/Disassembler version 20170831 +Copyright (c) 2000 - 2017 Intel Corporation + +Input file aml-4L677Y, Length 0x38 (56) bytes +Table [TEPH] is too long for file - needs: 0x38000000, remaining in file: 0x38 +Could not get ACPI tables from aml-4L677Y, AE_BAD_HEADER + + +At first I thought this was an iasl bug, but the latest version of iasl in rawhide is ported to big endian. + +So I looked at the actual AML files that bios-tables-test extracts from the qemu-system-x86_64 memory space, when running on ppc64 host. These do indeed have different content from the AML files generated by qemu-system-x86_64 when running on an x86_64 host. + + +eg the AML file for the HPET shows + +< 0000000 T E P H nul nul nul 8 soh etx B O C H S sp +< 4554 4850 0000 3800 0301 4f42 4843 2053 +< 0000020 B X P C H P E T nul nul nul soh B X P C +< 5842 4350 5048 5445 0000 0100 5842 4350 +< 0000040 nul nul nul soh soh " ack nul nul nul nul nul nul nul P ~ +< 0000 0100 a201 8086 0000 0000 0000 fed0 +--- +> 0000000 H P E T 8 nul nul nul soh etx B O C H S sp +> 5048 5445 0038 0000 0301 4f42 4843 2053 +> 0000020 B X P C H P E T soh nul nul nul B X P C +> 5842 4350 5048 5445 0001 0000 5842 4350 +> 0000040 soh nul nul nul soh " ack nul nul nul nul nul nul nul P ~ +> 0001 0000 a201 8086 0000 0000 0000 fed0 + +so not only is the table name inverted, but the lenght is inverted, and several fields later on are inverted too. + +Other AML files for APIC and DSDT show similar brokenness + +This is seen with QEMU 2.10.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1726 b/results/classifier/gemma3:12b/hypervisor/1726 new file mode 100644 index 00000000..40cccd02 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1726 @@ -0,0 +1,98 @@ + +qemu-system-ppc64 option -smp 2 broken with commit 20b6643324a79860dcdfe811ffe4a79942bca21e +Description of problem: +I was trying to boot rhel9 image with upstream qemu-system-ppc64 -smp 2 option and observed a segfault (qemu crash). +After doing a git bisect, I found the first bad commit which introduced this issue is below: +``` +[qemu]# git bisect good +20b6643324a79860dcdfe811ffe4a79942bca21e is the first bad commit +commit 20b6643324a79860dcdfe811ffe4a79942bca21e +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Mon Dec 5 17:45:02 2022 -0600 + + tcg/ppc: Reorg goto_tb implementation + + The old ppc64 implementation replaces 2 or 4 insns, which leaves a race + condition in which a thread could be stopped at a PC in the middle of + the sequence, and when restarted does not see the complete address + computation and branches to nowhere. + + The new implemetation replaces only one insn, swapping between + + b <dest> + and + mtctr r31 + + falling through to a general-case indirect branch. + + Reviewed-by: Alex Bennée <alex.bennee@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + + tcg/ppc/tcg-target.c.inc | 152 +++++++++++++---------------------------------- + tcg/ppc/tcg-target.h | 3 +- + 2 files changed, 41 insertions(+), 114 deletions(-) +[qemu]# +``` +Steps to reproduce: +1. Run the qemu command line mentioned +2. Wait for the qemu to crash. +Additional information: +git bisect log: +``` +[root@ltcden6-lp2 qemu]# git bisect log +git bisect start +# status: waiting for both good and bad commits +# bad: [b455ce4c2f300c8ba47cba7232dd03261368a4cb] Merge tag 'q800-for-8.1-pull-request' of https://github.com/vivier/qemu-m68k into staging +git bisect bad b455ce4c2f300c8ba47cba7232dd03261368a4cb +# status: waiting for good commit(s), bad commit known +# good: [b247dba067bf2808de6395ff09ff0cb220ed7c95] tests/avocado: add explicit timeout for ppc64le TCG tests +git bisect good b247dba067bf2808de6395ff09ff0cb220ed7c95 +# bad: [3db629f03e8caf39526cd0415dac16a6a6484107] Merge tag 'pull-request-2023-02-27' of https://gitlab.com/thuth/qemu into staging +git bisect bad 3db629f03e8caf39526cd0415dac16a6a6484107 +# good: [777fa06376ce0249c76d0d852e8f7ed103a63864] Merge tag 'pull-loongarch-20221202' of https://gitlab.com/gaosong/qemu into staging +git bisect good 777fa06376ce0249c76d0d852e8f7ed103a63864 +# bad: [c66ffcd5358ba88e93e1ffb15ae42ca52dab12a8] target/riscv/cpu: set cpu->cfg in register_cpu_props() +git bisect bad c66ffcd5358ba88e93e1ffb15ae42ca52dab12a8 +# good: [bc92f261519d5c77c70cf2ebcf0a3b9a414d82d0] hw/intc: sifive_plic: Fix the pending register range check +git bisect good bc92f261519d5c77c70cf2ebcf0a3b9a414d82d0 +# good: [aa96ab7c9df59c615ca82b49c9062819e0a1c287] Merge tag 'pull-request-2023-01-09' of https://gitlab.com/thuth/qemu into staging +git bisect good aa96ab7c9df59c615ca82b49c9062819e0a1c287 +# good: [a8d6abe1292e1db1ad9be5b2b124b9c01bcda094] Merge tag 'mips-20230113' of https://github.com/philmd/qemu into staging +git bisect good a8d6abe1292e1db1ad9be5b2b124b9c01bcda094 +# bad: [ef4f031fab7b070816454949a1b6b6c7aa3cf503] Merge tag 'pull-tcg-20230117' of https://gitlab.com/rth7680/qemu into staging +git bisect bad ef4f031fab7b070816454949a1b6b6c7aa3cf503 +# good: [0fe1c98da9d9abb8e5dc4a67c7e3bcf19aad1e85] tcg: Change tb_target_set_jmp_target arguments +git bisect good 0fe1c98da9d9abb8e5dc4a67c7e3bcf19aad1e85 +# good: [701ed34833f53880ba38bde09b0846d01fc16d66] Merge tag 'pull-request-2023-01-18' of https://gitlab.com/thuth/qemu into staging +git bisect good 701ed34833f53880ba38bde09b0846d01fc16d66 +# bad: [20b6643324a79860dcdfe811ffe4a79942bca21e] tcg/ppc: Reorg goto_tb implementation +git bisect bad 20b6643324a79860dcdfe811ffe4a79942bca21e +# good: [90c0fee3a28b25d23081b3c435762cadde813ec4] tcg: Always define tb_target_set_jmp_target +git bisect good 90c0fee3a28b25d23081b3c435762cadde813ec4 +# good: [d59d83a1c38869b1e1a4f957eb939aaa8a342721] tcg/aarch64: Reorg goto_tb implementation +git bisect good d59d83a1c38869b1e1a4f957eb939aaa8a342721 +# first bad commit: [20b6643324a79860dcdfe811ffe4a79942bca21e] tcg/ppc: Reorg goto_tb implementation +``` + +gdb backtrace output: + +``` +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x00007fff4becfa8c in ?? () +[Current thread is 1 (Thread 0x7fff9e80e780 (LWP 31456))] +(gdb) bt +#0 0x00007fff4becfa8c in () +#1 0x00007fff5682d044 in code_gen_buffer () +#2 0x000000013e3224ec in cpu_tb_exec (cpu=cpu@entry=0x16144fb70, itb=itb@entry=0x7fff5682cf00 <code_gen_buffer+111332932>, tb_exit=tb_exit@entry=0x7fff9e80d7f0) at ../accel/tcg/cpu-exec.c:438 +#3 0x000000013e322ad4 in cpu_loop_exec_tb (tb_exit=0x7fff9e80d7f0, last_tb=<synthetic pointer>, pc=13835058055286981664, tb=0x7fff5682cf00 <code_gen_buffer+111332932>, cpu=<optimized out>) + at ../accel/tcg/cpu-exec.c:871 +#4 cpu_exec_loop (cpu=cpu@entry=0x16144fb70, sc=sc@entry=0x7fff9e80d940) at ../accel/tcg/cpu-exec.c:981 +#5 0x000000013e3234e8 in cpu_exec_setjmp (cpu=cpu@entry=0x16144fb70, sc=sc@entry=0x7fff9e80d940) at ../accel/tcg/cpu-exec.c:1012 +#6 0x000000013e323e64 in cpu_exec (cpu=0x16144fb70) at ../accel/tcg/cpu-exec.c:1038 +#7 0x000000013e35bba0 in tcg_cpus_exec (cpu=0x16144fb70) at ../accel/tcg/tcg-accel-ops.c:69 +#8 0x000000013e35bd90 in mttcg_cpu_thread_fn (arg=0x16144fb70) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#9 0x000000013e57193c in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:505 +#10 0x00007fffa12aa0f0 in start_thread (arg=0x7fff9e80e780) at pthread_create.c:443 +#11 0x00007fffa1352ec8 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107 +``` +For any further additional information contact me at : anushree.mathur@linux.vnet.ibm.com diff --git a/results/classifier/gemma3:12b/hypervisor/1728 b/results/classifier/gemma3:12b/hypervisor/1728 new file mode 100644 index 00000000..1f6c50a2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1728 @@ -0,0 +1,19 @@ + +blockdev parameter does not accept dots in pool name in json config +Description of problem: +I'm trying to provision a VM using qemu 6.2.0 and pass the remote disk parameters like libvirt. When I start the VM, I get an error saying + + +``` +qemu-system-x86_64: -blockdev {driver:rbd,pool:cloud.disk.hiops,image:csi-vol-8577fffd-0f48-3344-b333-02000038163a,server:[{host:1.2.3.4,port:6789},{host:1.2.3.5,port:6789},{host:1.2.3.6,port:6789}],user:compute-staging,auth-client-required:[cephx,none],key-secret:ceph-secret,node-name:pv-MD7PBV3SRD21L08115JUJ94HMG,cache:{direct:false,no-flush:false},auto-read-only:true,discard:unmap}: JSON parse error, stray '.' +``` + + +I changed the ip address and some fields. + + +My question is should we avoid dots in pool name? I tried to look at the source code of json parser but in its doc, it did not mention a sequence of characters for escaping dots. +Steps to reproduce: +1. Provision a VM with the provided config +Additional information: +bl diff --git a/results/classifier/gemma3:12b/hypervisor/1728615 b/results/classifier/gemma3:12b/hypervisor/1728615 new file mode 100644 index 00000000..24708dfc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1728615 @@ -0,0 +1,166 @@ + +qemu-io crashes with SIGABRT and Assertion `c->entries[i].offset != 0' failed + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached files named backing_img.file and test.img to a directory +2. And customize the following command to point to the above directory and run the same. +/usr/bin/qemu-io <path to>/test.img -c "write 1352192 1707520" + +3.Output of the above command. +qemu-io: block/qcow2-cache.c:411: qcow2_cache_entry_mark_dirty: Assertion `c->entries[i].offset != 0' failed. +Aborted (core dumped) + +from gdb: +(gdb) bt +#0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +#1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +#2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +#4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +#5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +#6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) + at block/qcow2-refcount.c:834 +#7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +#8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) + at block/qcow2-cluster.c:1221 +#9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1324 +#10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1511 +#11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +#12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +#13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) + at block/io.c:1440 +#14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +#15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +#16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +#17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +#18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +#19 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +No symbol table info available. +#2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +No symbol table info available. +#3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +No symbol table info available. +#4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 + i = 0 + __PRETTY_FUNCTION__ = "qcow2_cache_entry_mark_dirty" +#5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 + s = 0x2e893210 + refcount_table_index = 0 + ret = 0 + new_block = 0 + blocks_used = 72057594818669408 + meta_offset = 1572863 +#6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) + at block/qcow2-refcount.c:834 + block_index = 268870408 + refcount = 780741808 + cluster_index = 2 + table_index = 0 + s = 0x2e893210 + start = 1048576 + last = 1048576 + cluster_offset = 1048576 + refcount_block = 0x3fff81200000 + old_table_index = -1 + ret = 16383 +#7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 + s = 0x2e893210 + cluster_index = 3 + refcount = 0 + i = 1 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_clusters_at" +#8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) + at block/qcow2-cluster.c:1221 + ret = 780743184 + s = 0x2e893210 +#9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1324 + s = 0x2e893210 + l2_index = 4 + l2_table = 0x0 + entry = 0 + nb_clusters = 1 + ret = 0 +---Type <return> to continue, or q <return> to quit--- + keep_old_clusters = false + alloc_cluster_offset = 1048576 + __PRETTY_FUNCTION__ = "handle_alloc" + requested_bytes = 17960562528 + avail_bytes = -2133853344 + nb_bytes = 16383 + old_m = 0x100000000 +#10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1511 + s = 0x2e893210 + start = 2097152 + remaining = 962560 + cluster_offset = 1048576 + cur_bytes = 962560 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +#11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 + s = 0x2e893210 + offset_in_cluster = 0 + ret = 0 + cur_bytes = 1486848 + cluster_offset = 524288 + hd_qiov = {iov = 0x2e858660, niov = 1, nalloc = 1, size = 220672} + bytes_done = 220672 + cluster_data = 0x0 + l2meta = 0x0 + __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +#12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 + drv = 0x102036f0 <bdrv_qcow2> + sector_num = 780706080 + nb_sectors = 3069122264 + ret = -203160320 + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) + at block/io.c:1440 + bs = 0x2e886f60 + drv = 0x102036f0 <bdrv_qcow2> + waited = false + ret = 0 + end_sector = 5976 + bytes_remaining = 1707520 + max_transfer = 2147483647 + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 + bs = 0x2e886f60 + req = {bs = 0x2e886f60, offset = 1352192, bytes = 1707520, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 1352192, + overlap_bytes = 1707520, list = {le_next = 0x0, le_prev = 0x2e88a1d8}, co = 0x2e895a90, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fff80cffe20}}, waiting_for = 0x0} + align = 1 + head_buf = 0x0 +---Type <return> to continue, or q <return> to quit--- + tail_buf = 0x0 + local_qiov = {iov = 0x3fff80cffdb0, niov = -2133852688, nalloc = 16383, size = 1352192} + use_local_qiov = false + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 + ret = 0 + bs = 0x2e886f60 +#16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 + rwco = 0x3fffc85f0c08 +#17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x2e895a90, i = {780753552, 0}} + self = 0x2e895a90 + co = 0x2e895a90 +#18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#19 0x0000000000000000 in ?? () +No symbol table info available. + +Will attach the 'image_fuzzer' images. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1728635 b/results/classifier/gemma3:12b/hypervisor/1728635 new file mode 100644 index 00000000..fb618640 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1728635 @@ -0,0 +1,172 @@ + +qemu-io crashes with SIGSEGV when did -c aio_write 9233408 28160 on a image_fuzzer image + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached file named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# cp test.img copy.img +# qemu/qemu-io <path to>/copy.img -c "aio_write 9233408 28160" + +from gdb: +Program terminated with signal 11, Segmentation fault. +#0 0x00003fffa0077644 in __memcpy_power7 () from /lib64/libc.so.6 +Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-21.el7.ppc64le glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libcom_err-1.42.9-10.el7.ppc64le libcurl-7.29.0-42.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcc-4.8.5-16.el7_4.1.ppc64le libidn-1.28-4.el7.ppc64le libselinux-2.5-11.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le libstdc++-4.8.5-16.el7_4.1.ppc64le libtasn1-4.10-1.el7.ppc64le nettle-2.7.1-8.el7.ppc64le nspr-4.13.1-1.0.el7_3.ppc64le nss-3.28.4-15.el7_4.ppc64le nss-softokn-freebl-3.28.3-8.el7_4.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le +(gdb) bt +#0 0x00003fffa0077644 in __memcpy_power7 () from /lib64/libc.so.6 +#1 0x0000000010056738 in qcow2_refcount_area (bs=0x25f56f60, start_offset=137438953472, additional_clusters=0, exact_size=false, new_refblock_index=0, + new_refblock_offset=524288) at block/qcow2-refcount.c:573 +#2 0x0000000010056374 in alloc_refcount_block (bs=0x25f56f60, cluster_index=0, refcount_block=0x3fff9dadf838) at block/qcow2-refcount.c:479 +#3 0x0000000010057520 in update_refcount (bs=0x25f56f60, offset=0, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) + at block/qcow2-refcount.c:834 +#4 0x0000000010057c24 in qcow2_alloc_clusters (bs=0x25f56f60, size=524288) at block/qcow2-refcount.c:996 +#5 0x0000000010063684 in do_alloc_cluster_offset (bs=0x25f56f60, guest_offset=9233408, host_offset=0x3fff9dadf9e0, nb_clusters=0x3fff9dadf9d8) + at block/qcow2-cluster.c:1213 +#6 0x0000000010063afc in handle_alloc (bs=0x25f56f60, guest_offset=9233408, host_offset=0x3fff9dadfab0, bytes=0x3fff9dadfab8, m=0x3fff9dadfb60) + at block/qcow2-cluster.c:1324 +#7 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x25f56f60, offset=9233408, bytes=0x3fff9dadfb4c, host_offset=0x3fff9dadfb58, m=0x3fff9dadfb60) + at block/qcow2-cluster.c:1511 +#8 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x25f56f60, offset=9233408, bytes=28160, qiov=0x25f6fa08, flags=0) at block/qcow2.c:1919 +#9 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x25f56f60, offset=9233408, bytes=28160, qiov=0x25f6fa08, flags=16) at block/io.c:898 +#10 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x25f627f0, req=0x3fff9dadfdd8, offset=9233408, bytes=28160, align=1, qiov=0x25f6fa08, flags=16) + at block/io.c:1440 +#11 0x00000000100ac4ac in bdrv_co_pwritev (child=0x25f627f0, offset=9233408, bytes=28160, qiov=0x25f6fa08, flags=BDRV_REQ_FUA) at block/io.c:1691 +#12 0x000000001008da0c in blk_co_pwritev (blk=0x25f49410, offset=9233408, bytes=28160, qiov=0x25f6fa08, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +#13 0x000000001008e718 in blk_aio_write_entry (opaque=0x25f6fa70) at block/block-backend.c:1276 +#14 0x00000000101aa444 in coroutine_trampoline (i0=636902032, i1=0) at util/coroutine-ucontext.c:79 +#15 0x00003fffa0022b9c in makecontext () from /lib64/libc.so.6 +#16 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00003fffa0077644 in __memcpy_power7 () from /lib64/libc.so.6 +No symbol table info available. +#1 0x0000000010056738 in qcow2_refcount_area (bs=0x25f56f60, start_offset=137438953472, additional_clusters=0, exact_size=false, new_refblock_index=0, + new_refblock_offset=524288) at block/qcow2-refcount.c:573 + s = 0x25f63210 + total_refblock_count_u64 = 2 + additional_refblock_count = 0 + total_refblock_count = 2 + table_size = 65536 + area_reftable_index = 1 + table_clusters = 1 + i = 0 + table_offset = 268870620 + block_offset = 70367094634128 + end_offset = 636891296 + ret = 636786432 + new_table = 0x3fff9d940010 + __PRETTY_FUNCTION__ = "qcow2_refcount_area" + data = {d64 = 636841824, d32 = 1} + old_table_offset = 70367094634552 + old_table_size = 636786432 +#2 0x0000000010056374 in alloc_refcount_block (bs=0x25f56f60, cluster_index=0, refcount_block=0x3fff9dadf838) at block/qcow2-refcount.c:479 + s = 0x25f63210 + refcount_table_index = 0 + ret = 0 + new_block = 524288 + blocks_used = 1 + meta_offset = 137438953472 +#3 0x0000000010057520 in update_refcount (bs=0x25f56f60, offset=0, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) + at block/qcow2-refcount.c:834 + block_index = 268794524 + refcount = 4563798300 + cluster_index = 0 + table_index = 0 + s = 0x25f63210 + start = 0 + last = 0 + cluster_offset = 0 + refcount_block = 0x0 + old_table_index = -1 + ret = 0 +#4 0x0000000010057c24 in qcow2_alloc_clusters (bs=0x25f56f60, size=524288) at block/qcow2-refcount.c:996 + offset = 0 + ret = 0 +#5 0x0000000010063684 in do_alloc_cluster_offset (bs=0x25f56f60, guest_offset=9233408, host_offset=0x3fff9dadf9e0, nb_clusters=0x3fff9dadf9d8) + at block/qcow2-cluster.c:1213 + cluster_offset = 0 + s = 0x25f63210 +#6 0x0000000010063afc in handle_alloc (bs=0x25f56f60, guest_offset=9233408, host_offset=0x3fff9dadfab0, bytes=0x3fff9dadfab8, m=0x3fff9dadfb60) + at block/qcow2-cluster.c:1324 +---Type <return> to continue, or q <return> to quit--- + s = 0x25f63210 + l2_index = 17 + l2_table = 0x0 + entry = 0 + nb_clusters = 1 + ret = 0 + keep_old_clusters = false + alloc_cluster_offset = 0 + __PRETTY_FUNCTION__ = "handle_alloc" + requested_bytes = 73651285856 + avail_bytes = -1649542304 + nb_bytes = 16383 + old_m = 0x3fff00000000 +#7 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x25f56f60, offset=9233408, bytes=0x3fff9dadfb4c, host_offset=0x3fff9dadfb58, m=0x3fff9dadfb60) + at block/qcow2-cluster.c:1511 + s = 0x25f63210 + start = 9233408 + remaining = 28160 + cluster_offset = 0 + cur_bytes = 28160 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +#8 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x25f56f60, offset=9233408, bytes=28160, qiov=0x25f6fa08, flags=0) at block/qcow2.c:1919 + s = 0x25f63210 + offset_in_cluster = 320512 + ret = 0 + cur_bytes = 28160 + cluster_offset = 0 + hd_qiov = {iov = 0x25f285a0, niov = 0, nalloc = 1, size = 0} + bytes_done = 0 + cluster_data = 0x0 + l2meta = 0x0 + __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +#9 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x25f56f60, offset=9233408, bytes=28160, qiov=0x25f6fa08, flags=16) at block/io.c:898 + drv = 0x102036f0 <bdrv_qcow2> + sector_num = 636854560 + nb_sectors = 598850083 + ret = -1802855680 + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#10 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x25f627f0, req=0x3fff9dadfdd8, offset=9233408, bytes=28160, align=1, qiov=0x25f6fa08, flags=16) + at block/io.c:1440 + bs = 0x25f56f60 + drv = 0x102036f0 <bdrv_qcow2> + waited = false + ret = 0 + end_sector = 18089 + bytes_remaining = 28160 + max_transfer = 2147483647 + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#11 0x00000000100ac4ac in bdrv_co_pwritev (child=0x25f627f0, offset=9233408, bytes=28160, qiov=0x25f6fa08, flags=BDRV_REQ_FUA) at block/io.c:1691 +---Type <return> to continue, or q <return> to quit--- + bs = 0x25f56f60 + req = {bs = 0x25f56f60, offset = 9233408, bytes = 28160, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 9233408, + overlap_bytes = 28160, list = {le_next = 0x0, le_prev = 0x25f5a1d8}, co = 0x25f65a90, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fff9dadfe20}}, waiting_for = 0x0} + align = 1 + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x3fff9dadfdb0, niov = -1649541648, nalloc = 16383, size = 9233408} + use_local_qiov = false + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#12 0x000000001008da0c in blk_co_pwritev (blk=0x25f49410, offset=9233408, bytes=28160, qiov=0x25f6fa08, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 + ret = 0 + bs = 0x25f56f60 +#13 0x000000001008e718 in blk_aio_write_entry (opaque=0x25f6fa70) at block/block-backend.c:1276 + acb = 0x25f6fa70 + rwco = 0x25f6fa98 + __PRETTY_FUNCTION__ = "blk_aio_write_entry" +#14 0x00000000101aa444 in coroutine_trampoline (i0=636902032, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x25f65a90, i = {636902032, 0}} + self = 0x25f65a90 + co = 0x25f65a90 +#15 0x00003fffa0022b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#16 0x0000000000000000 in ?? () +No symbol table info available. + +Will be attaching image_fuzzer image \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1735049 b/results/classifier/gemma3:12b/hypervisor/1735049 new file mode 100644 index 00000000..fced215d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1735049 @@ -0,0 +1,8 @@ + +Need MTTCG support for x86 guests + +MTTCG support is notably absent for x86_64 guests. The last Wiki update on MTTCG was back in 2015, and I am having some difficulty determining the current status of the underlying requirements to enable this feature on x86 hosts. + +For instance, has support for strong-on-weak memory consistency been added into QEMU GIT at this point? + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1735384 b/results/classifier/gemma3:12b/hypervisor/1735384 new file mode 100644 index 00000000..538cbbfb --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1735384 @@ -0,0 +1,21 @@ + +OpenJDK JVM segfaults on qemu-sh4 (regression) + +Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: + +(sid-sh4-sbuild)root@nofan:/# java -version +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +(sid-sh4-sbuild)root@nofan:/# + +An older version works fine: + +(sid-sh4-sbuild)root@nofan:/# java -version +openjdk version "9.0.1" +OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +(sid-sh4-sbuild)root@nofan:/# + +Haven't had time for bisecting this yet. + +Adrian \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1735576 b/results/classifier/gemma3:12b/hypervisor/1735576 new file mode 100644 index 00000000..d5d3e1e2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1735576 @@ -0,0 +1,25 @@ + +Support more than 4G memory for guest with Intel HAXM acceleration + +setup: + +host: windows 7 professional 64bit +guest: centos 7 +qemu 2.10.92 +haxm 6.2.1 + +issue: when assign 4096M or more memory to the guest, I got following error message: +E:\qemuvm\vm-svr>qemu-system-x86_64 -accel hax -hda centos-1.vdi -m 4096 +HAX is working and emulator runs in fast virt mode. +Failed to allocate 0 memory +hax_transaction_commit: Failed mapping @0x0000000000000000+0xc0000000 flags 00 +hax_transaction_commit: Failed mapping @0x0000000100000000+0x40000000 flags 00 +VCPU shutdown request +VCPU shutdown request +if I change memory to 4095M, guest VM boot up without issue + +E:\qemuvm\vm-svr>qemu-system-x86_64 -accel hax -hda centos-1.vdi -m 4095 +HAX is working and emulator runs in fast virt mode. + + +This is known limitation, I already raised a request on HAXM github site for fix this: https://github.com/intel/haxm/issues/13, and it got accepted will be fixed in next haxm release; however it seems there is also qemu side work (according to haxm dev), so I raise this for qemu side fix; \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1739413 b/results/classifier/gemma3:12b/hypervisor/1739413 new file mode 100644 index 00000000..63a9dc6e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1739413 @@ -0,0 +1,51 @@ + +Hotplugged vcpu does not guarantee cpu compat mode(power8) on power9 host + +./ppc64-softmmu/qemu-system-ppc64 -version +QEMU emulator version 2.11.50 (v2.11.0-254-gaf35267) + +1. Boot a power8 compat mode guest power9 HW. +./ppc64-softmmu/qemu-system-ppc64 -machine pseries,accel=kvm,max-cpu-compat=power8 -m 4096 /home/sath/images/guest.qcow2 -smp 1,maxcpus=2 -serial /dev/pts/8 -monitor stdio -vga none -nographic +QEMU 2.11.50 monitor - type 'help' for more information +(qemu) + +2. Check for cpuinfo + +# cat /proc/cpuinfo +processor : 0 +cpu : POWER8 (architected), altivec supported +clock : 2200.000000MHz +revision : 2.1 (pvr 004e 1201) + +timebase : 512000000 +platform : pSeries +model : IBM pSeries (emulated by qemu) +machine : CHRP IBM pSeries (emulated by qemu) +MMU : Hash + + +3. Run a small program invoking isa v3.0 instruction, it should complain 'Illegal instruction' as it is a power8 compat guest +# cat 1.c +#include <stdio.h> +void main() + { + asm volatile (".long 0x7c0005e6"); + } +# ./a.out +[ 59.352795] a.out[1741]: unhandled signal 4 at 0000000010000600 nip 0000000010000600 lr 00007fffb4da5080 code 1 +Illegal instruction + +4. Hotplug a vcpu +(qemu) device_add host-spapr-cpu-core,id=core1,core-id=1 +(qemu) info cpus +* CPU #0: nip=0xc0000000000de42c thread_id=113110 + CPU #1: nip=0xc0000000000de42c thread_id=113348 + +5. Try running the same program in the hotplugged vcpu and it does not complain as 'Illegal instruction' + +#taskset -c 1 ./a.out ----------------------NOK +# + +# taskset -c 0 ./a.out +[ 356.618031] a.out[1755]: unhandled signal 4 at 0000000010000600 nip 0000000010000600 lr 00007fffae7f5080 code 1 +Illegal instruction \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1751 b/results/classifier/gemma3:12b/hypervisor/1751 new file mode 100644 index 00000000..3a20ffd8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1751 @@ -0,0 +1,2 @@ + +s390 host: helper_st16_mmu: Assertion `(get_memop(oi) & MO_SIZE) == MO_128' failed diff --git a/results/classifier/gemma3:12b/hypervisor/1754542 b/results/classifier/gemma3:12b/hypervisor/1754542 new file mode 100644 index 00000000..7b5d8b2f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1754542 @@ -0,0 +1,69 @@ + +colo: vm crash with segmentation fault + +I use Arch Linux x86_64 +both qemu 2.11.1 Zhang Chen's(https://github.com/zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +Following document 'COLO-FT.txt', +I test colo feature on my hosts + +I run this command +Primary: +sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name primary \ +-device piix3-usb-uhci \ +-device usb-tablet -netdev tap,id=hn0,vhost=off \ +-device virtio-net-pci,id=net-pci0,netdev=hn0 \ +-drive if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/var/lib/libvirt/images/1.raw,children.0.driver=raw -S + +Secondary: +sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name secondary \ +-device piix3-usb-uhci \ +-device usb-tablet -netdev tap,id=hn0,vhost=off \ +-device virtio-net-pci,id=net-pci0,netdev=hn0 \ +-drive if=none,id=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0 \ +-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +file.driver=qcow2,top-id=active-disk0,\ +file.file.filename=/mnt/ramfs/active_disk.img,\ +file.backing.driver=qcow2,\ +file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +file.backing.backing=colo-disk0 \ +-incoming tcp:0:8888 + +Secondary: +{'execute':'qmp_capabilities'} +{ 'execute': 'nbd-server-start', + 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.33', 'port': '8889'} } } +} +{'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', 'writable': true } } + +Primary: +{'execute':'qmp_capabilities'} +{ 'execute': 'human-monitor-command', + 'arguments': {'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.33,file.port=8889,file.export=colo-disk0,node-name=nbd_client0'}} +{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node': 'nbd_client0' } } +{ 'execute': 'migrate-set-capabilities', + 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } } +{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.33:8888' } } +{ 'execute': 'migrate-set-parameters' , 'arguments':{ 'x-checkpoint-delay': 2000 } } + +Above are all OK.Two VM syncing. + +Primary: +{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} +{ 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del blk-buddy0'}} + +Secondary: +{ 'execute': 'nbd-server-stop' } +{ 'execute': 'x-colo-lost-heartbeat' } + +But When I execute x-colo-lost-heartbeat.Primary run Secondary cash + + + { 'execute': 'nbd-server-stop' } +{"return": {}} +qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file before all bytes were read + { 'execute': 'x-colo-lost-heartbeat' } +{"return": {}} +qemu-system-x86_64: Can't receive COLO message: Input/output error +** +ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: assertion failed (obj->ref > 0): (0 > 0) +[1] 2972 abort sudo /usr/bin/qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdi \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1754656 b/results/classifier/gemma3:12b/hypervisor/1754656 new file mode 100644 index 00000000..e33ae142 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1754656 @@ -0,0 +1,162 @@ + +Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM + +Version: + +QEMU emulator version 2.11.1 + +Introduction: + +This is call for action to get attention of somebody in QEMU project/organization, who is capable of actually doing something about this pressing issue. This might be TLDR for some, but that's only because of the complexity of the issue. Please read this with open mind. + +Problem: + +As QEMU users, we need (it is a requirement) to have some mechanism in place, to somehow convert simple POSIX signal sent form host, into graceful ACPI shutdown of the guest. This signal, due various historical reasons and daemon design, must be SIGTERM foremost. + +Status quo: + +After wading through mailing lists and bug tracker I concluded that this is "political" problem and I am in search of somebody, a "politician" within QEMU project, who will help us reach conclusion to this problem. + +First I will present analysis of the situation, and then propose some suggestions for solutions. + +Even then, any of these proposals might be, potentially, seen as problematic in eyes of QEMU maintainers, developers, dictators, long term users or their dogs. + +That's why we need somebody willing, "higher up the chain" or whatever, to orchestrate discussion so that we can actually reach consensus in the matter, solution that is acceptable to **everyone**. + +Analysis: + +Each QEMU emulated virtual machine (vm), running in the host system, is represented by single qemu-* process (followed by several threads). Thus for all intents and purposes, any such instantiated vm, must be seen as it's own, separate, daemon. + +I repeat running qemu-* vm **is a daemon**. + +QEMU provides incredible IO redirection capabilities, so we don't need to get into issues of logging, console and monitor redirections and such, as this is already a (perfectly) solved problem. + +What we cannot currently do, at least easily, reliably and simply, is to shutdown guest gracefully from "outside". + +That is not a problem for those of us, who use some kind of higher level orchestrator (I think one of them is virsh, but this is not important in this matter) that takes care of this by communicating with QEMU directly (I guess this is done by sending commands to internal monitor by pipe (or socket) held open by mentioned orchestrator). + +However it is a problem for those of us, who run qemu-* processes bare or supervised. + +Let's say I, as administrator, want to implement vm instance as supervised service. +I can use any supervisor for that, systemd even. Let us not get into into supervisor wars. + +At basic level almost all supervisors are similar. Supervisor usually is yet another process, that "leads" the qemu-* one. + +In case of systemd it is PID1, but in case of other supervision schemes, like daemontools, runit, s6 or nosh, it is separate '*supervise' process instead. + +When such supervisor is tearing down the service, "leading"/supervising, parent will send SIGTERM to it's child qemu-* process. + +This behaviour is almost universal among all supervisors. This due the fact, that it is customary for daemons to cease all operations and exit cleanly when receiving SGITERM signal. If daemon child fails to exit within configurable timeframe, supervisor deals with it by the means of SIGKILL. + +As such, one would expect, similarly, for qemu-* process to send ACPI shutdown event to guest internally (roughly equivalent to 'system_powerdown' monitor command) on SIGTERM reception. + +But this is not what happens! + +Instead, qemu-* just flushes pending IO and kills the guest instantly. + +Then, on next vm "boot", guest detects this as power failure event, and performs fsck checks and other things, it is supposed to do in case of power failure. We are not mentioning possible data loss that might have happened due to this behavior, either. + +Some supervisors (like systemd for example) might provide feature to change "termiante operations" signal to something else like SIGTERM, but that is not universal supervisor feature by any means. Default action for any proper daemon is to cleanly terminate on SIGTERM. + +That is why we need ability to somehow instruct QEMU to **always** perform graceful ACPI shutdown on SIGTERM. + +Potential reply to this bug saying that one should send 'system_powerdown' over monitor connection won't fly! + +As it is not always possible (nor required) to hook into supervisor's signal processing (main reason being intentional supervisor simplicity in search of extreme reliability, and de facto standardized behavior of daemons to exit cleanly on SIGTERM). + +More over, in situations like machine reboot, most supervisors won't play around with signal remapping, they will simply send out SIGTERM to all supervised processes. We want our qemu-* instances to come up undamaged from such action (on next host reboot) and not have them stuck in fscks (or worse - ending up damaged) . + +If this can be extended further, inside QEMU, with internal signal to action remapping, the better, but supporting graceful shutdown on SIGTERM is hard requirement. + +Proposed solutions: + +0. modify QEMU so that it emits ACPI shutdown event equivalent to 'system_powerdown' monitor command by default + - this seems to be a "no go", with backwards compat. and "current users expectations" + cited as the reasons + - I won't go into a fact that QEMU changed option handling without BOLD notice few times + +1. add single switch '-graceful-shutdown-on-sgiterm' + - this was rejected when person tried to submit patch implementing something similar + to what I am requesting, only bound to SIGHUP + - that person (implementing graceful poweroff on SIGHUP) was wrong, almost no + supervision scheme in existence sends out SIGHUP on service termination request, + although all supervisors are able to send out SIGHUP when instructed + - in daemons SIGHUP is usually reserved for "daemon reload" which can be interpreted + like "reboot" in QEMU context + - if we see qemu-* proces for what it is, a daemon, it must react properly to SIGTERM foremost + +2. add ability to map internal monitor action commands to few signals like SIGTERM, SIGHUP, SIGINTR, SIGUSR1, SIGUSR2, SIGALARM etc + - this seems like best solution to me, that allows us to satisfy both + backwards compat. and "current users" requirement, yet allows us + to use qemu-* with proper supervision, and it even adds something extra + (I know some of these signals are used internally by QEMU) + - QEMU already has options parsing infrastructure in place to handle this nicely, something like: + : -signal SIGTERM,monitorcommand=system_powerdown -signal SIGHUP,monitorcommand=system_reset + would be great in this case + +3. add ability to map signals to executable scripts + - with this scheme QEMU would spawn child on signal reception, and this + script would then be used to perform the action + - this solution is most complex, most convoluted and most "flexible" + - for example with definition like this: + : -signal SIGTERM,script=signals/sigterm + qemu would perform this sequence of tasks: + - on SIGTERM qemu-* would spawn child script ./signals/sigterm + - this script would then pull out monitor fd descriptor from some kind of fd holder + - would write 'system_powerdown' command into monitor fd and terminate + - qemu-* would then read the command from monitor + - qemu-* would then interpret read-in command and gracefully terminate + - option parsing infrastructure is in place and QEMU is able to spawn and reap it's own children + which is proven by network up/down scripts + + +Of these, it seems that 0. and 1. are simplest to implement, yet "politically" unimplementable. + +More over QEMU people seem to be hard set on SIGTERM meaning "killing unresponsive guest". + +2. seems like most reasonable proposal that has potential to make everyone happy. It is also most reliable because internal QEMU command dispatch would have least chances to fail. + +3. is most flexible and can also be combined with 2. Reliability wise, there is slight chance signal handling script will fail to execute, leaving qemu-* at the mercy of supervisor (timeouted SIGKILL). + +Both 2 and 3 should probably provide configurable timeout after which QEMU would perform default action (eg. as it does now). + +Conclusion: + +I hope QEMU project members understand severity of the issue and are open to listed solutions. It might be that proposed solutions don't match QEMU project "spirit" perfectly. If so, I urge people capable of resolving this, to propose their versions. + +The fact is, that with proliferation of systemd, popularity of alternative supervisors is on the rise as well, but even under systemd, unintuitive handling of SIGTERM by bare QEMU processes is a problem. + +Further Reading: + +https://patchwork.kernel.org/patch/9626293/ + + - Daniel P. Berrange says: + "Because QEMU already designate that as doing an immediate stop - ie it'll + allow QEMU block layer to flush pending I/O, but it will not wait for the + guest to shutdown. If we change that behaviour we'll break anyone who + is already relying on SIGHUP - qemu might never exit at all if the guest + ignores the ACPI request" + + - this behaviour is incorrect if we perceive qemu-* process as daemon, proper, + yet it is, supposedly, entrenched in QEMU userbase + - signals remapping capability would allow us to keep the "old" behavior for entrenched users + while it would allow administrators and orchestrator writers to select signal disposition + they actually need + +https://bugs.launchpad.net/qemu/+bug/1217339 +and +https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03039.html + + - on my QEMU version of 2.11.1 SIGTERM just kills the guest without proper shutdown + - although thread says exit is graceful + - dicussion is problematic in several ways: + - SIGTERM is not intended to "terminate unresponsive guest" eg "terminate daemon uncleanly" + in any sane daemon in existence + - it means "terminate gracefully" + - if "terminate unresponsive guest" was true meaning of SIGTERM, databases like + mariadb or postgers would kill themselves on SIGTERM, leaving data in + inconsistent state, which they, of course, do not! + - some kind of "signal tapping" similar to "port tapping" is suggested + - this is non-obvious and error prone and nonstandard (no normal supervisor + will play such signal tapping games) + - signal remapping makes more sense in this regard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1756519 b/results/classifier/gemma3:12b/hypervisor/1756519 new file mode 100644 index 00000000..7468ce42 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1756519 @@ -0,0 +1,47 @@ + +qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create + +qemu-riscv64 version 2.11.50 (v2.11.0-2491-g2bb39a657a) crashes running gcc libgomp.c/sort-1.c testsuite test case with the following message: + +(process:11683): GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed +** +ERROR:qom/object.c:1665:object_get_canonical_path_component: code should not be reached +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60139c16 + + +Backtrace obtained via gdb: + +#0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x0000000060139b21 in abort () at abort.c:79 +#2 0x0000000060100505 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x60213ca1 "qom/object.c", line=line@entry=1665, + func=func@entry=0x60214420 <__func__.18106> "object_get_canonical_path_component", message=message@entry=0x7fffe8000cd0 "code should not be reached") + at gtestutils.c:2430 +#3 0x0000000060100586 in g_assertion_message_expr (domain=0x0, file=0x60213ca1 "qom/object.c", line=1665, + func=0x60214420 <__func__.18106> "object_get_canonical_path_component", expr=<optimized out>) at gtestutils.c:2453 +#4 0x0000000060098334 in object_get_canonical_path_component (obj=0x7fffe81340b0) at qom/object.c:1665 +#5 0x0000000060098366 in object_get_canonical_path (obj=0x7fffe81340b0) at qom/object.c:1675 +#6 0x000000006008e152 in device_set_realized (obj=0x7fffe81340b0, value=true, errp=0x7ffff762fe68) at hw/core/qdev.c:874 +#7 0x0000000060098bf4 in property_set_bool (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", opaque=0x7fffe80fd140, errp=0x7ffff762fe68) + at qom/object.c:1926 +#8 0x0000000060096fee in object_property_set (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1122 +#9 0x0000000060099ebd in object_property_set_qobject (obj=0x7fffe81340b0, value=0x7fffe80fd310, name=0x60213694 "realized", errp=0x7ffff762fe68) + at qom/qom-qobject.c:27 +#10 0x0000000060097274 in object_property_set_bool (obj=0x7fffe81340b0, value=true, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1191 +#11 0x0000000060092ec5 in cpu_create (typename=0x6250e1a0 "any-riscv-cpu") at qom/cpu.c:61 +#12 0x000000006009301a in cpu_generic_init (typename=0x601dd58f "riscv-cpu", cpu_model=0x601dd527 "any") at qom/cpu.c:98 +#13 0x000000006004cb61 in cpu_copy (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3881 +#14 0x000000006005b79a in do_fork (env=0x7ffff008cd60, flags=4001536, newsp=275531880704, parent_tidptr=275531882704, newtls=275531884288, + child_tidptr=275531882704) at /opt/qemu/linux-user/syscall.c:6348 +#15 0x0000000060063e56 in do_syscall (cpu_env=0x7ffff008cd60, num=220, arg1=4001536, arg2=275531880704, arg3=275531882704, arg4=275531884288, + arg5=275531882704, arg6=275531884288, arg7=0, arg8=0) at /opt/qemu/linux-user/syscall.c:10001 +#16 0x000000006004c89f in cpu_loop (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3600 +#17 0x000000006005b68f in clone_func (arg=0x7ffff7775050) at /opt/qemu/linux-user/syscall.c:6311 +#18 0x0000000060121797 in start_thread (arg=0x7ffff7632700) at pthread_create.c:463 +#19 0x000000006019b4fb in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + +Attached is a test case source code extracted from libgomp test suite. + +Note that it is a multi-threaded and requires 5 or more threads to fail. Number of launched threads is controlled by OMP_NUM_THREADS evironment variable, defaulting to number of hardware threads. Changing constants in the test case makes it fail with different numbers of threads. + +I will attach statically linked riscv64 binary executable if size limits permit. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1758819 b/results/classifier/gemma3:12b/hypervisor/1758819 new file mode 100644 index 00000000..694f8a07 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1758819 @@ -0,0 +1,6 @@ + +HVF Illegal instruction: 4, High Sierra, v2.12-rc0 + +I've built v2.12.0-rc0 on MacOS using homebrew. I'm running 10.13.3 on a 5,1 Mac Pro with a X5690 processor. + +When I run 'qemu-system-x86_64 -M accel=hvf', I get a crash "Illegal instruction: 4". \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1759333 b/results/classifier/gemma3:12b/hypervisor/1759333 new file mode 100644 index 00000000..77bcf371 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1759333 @@ -0,0 +1,8 @@ + +Illegal Instruction with HVF when encountering SSE instructions in the emulator + +The latest version of QEMU doesn't seem to support emulated SSE instructions with HVF acceleration on macOS. +The decoder will treat SSE instructions as invalid, get the instruction sizes wrong and quickly crash the guest OS because of illegal instructions. +After having a quick look at target/i386/hvf/x86_decode.c, it seems that SSE instruction emulation isn't implemented in the current version of the x86 emulator. + +A way to reproduce the issue is to run a macOS 10.13 guest with HVF acceleration enabled, this will crash once it's loading up the GUI. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1768246 b/results/classifier/gemma3:12b/hypervisor/1768246 new file mode 100644 index 00000000..0da5b9c9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1768246 @@ -0,0 +1,14 @@ + +cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. + +OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed. + +Crash indicates an assertion failure: + +(sid-sh4-sbuild)root@nofan:/# java --version +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +(sid-sh4-sbuild)root@nofan:/# + +Haven't bi-sected the issue yet, but will do so later. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1777293 b/results/classifier/gemma3:12b/hypervisor/1777293 new file mode 100644 index 00000000..eb75aa5a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1777293 @@ -0,0 +1,9 @@ + +[REQUEST] SHARING MEMORY WITH HOST + +Instead of a preallocated memory heap I would like for QEMU to share memory using shm. + +Example: Instead of using 16gb out of 32gb of ram to run Windows 10, there would be no option to allocate it, but to share the hosts resources; ie giving the host full access to the entire ram stack + + +I'm not a great programmer but I'm pretty sure QEMU's team could find this useful \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1784 b/results/classifier/gemma3:12b/hypervisor/1784 new file mode 100644 index 00000000..e7861632 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1784 @@ -0,0 +1,14 @@ + +Mac M1 Max / Debian guest / Luks password / Switching to graphical login manager (lightdm/Gdm) hangs in 75% +Description of problem: +In approximately 70% of cases I start QEMU with a Debian guest where the Debian guest was installed with full disk encryption, QEMU 'hangs' (does not respond') after I unlock the encrypted guest and the guest tries to start the graphical login manager (gdm or lightdm). + +I need to force quit QEMU, restart it multiple times until the start of the graphical login manager works. +Steps to reproduce: +1. Install Debian with (guided) full disk encryption and either the Gnome or the XFCE desktop environment +2. To be able to unlock the hard disk after the installation finished, the Linux boot parameter 'console=tty1' needs to be added within grub to the Linux command line +3. Try to restart/reboot QEMU several times and QEMU will become unresponsive multiple times in this process. +Additional information: +I encounter this problem for several months now, with different versions of QEMU, macOS and Debian. + +There is one observation, which might help: I installed [DropBear](https://packages.debian.org/buster/dropbear-initramfs) to experiment with remote unlocking of Luks encrypted Linux boxes. It seems, that QEMU does not go into the unresponsive state, when I unlock the hard disk via SSH and not focus the QEMU window until after the graphical login manager started. (Only tried remote unlocking a few times so it is too early to confirm if this works 100% of the time. diff --git a/results/classifier/gemma3:12b/hypervisor/1785308 b/results/classifier/gemma3:12b/hypervisor/1785308 new file mode 100644 index 00000000..68018d28 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1785308 @@ -0,0 +1,6 @@ + +0x8 exception encountered but not handled + +Present in all QEMU versions. + +OS is triple page faulting and crashing rather than handling the expected double page fault properly. The same OS works in Bochs so I know its not the problem. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1789751 b/results/classifier/gemma3:12b/hypervisor/1789751 new file mode 100644 index 00000000..5f89ea8d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1789751 @@ -0,0 +1,23 @@ + +Using -overcommit flag leads to qemu crashing + +Running the following leads to a qemu crash on startup: + +jwhite@laptop:~/os$ qemu-system-i386 -overcommit cpu-pm=on +qemu-system-i386: -overcommit cpu-pm=on: There is no option group 'overcommit' +Segmentation fault (core dumped) +jwhite@laptop:~/os$ + + +This fixes the issue: + +--- ../tmp/qemu-3.0.0/vl.c 2018-08-14 12:10:35.000000000 -0700 ++++ vl.c 2018-08-29 14:59:30.151554120 -0700 +@@ -2987,6 +2987,7 @@ + qemu_add_opts(&qemu_object_opts); + qemu_add_opts(&qemu_tpmdev_opts); + qemu_add_opts(&qemu_realtime_opts); ++ qemu_add_opts(&qemu_overcommit_opts); + qemu_add_opts(&qemu_msg_opts); + qemu_add_opts(&qemu_name_opts); + qemu_add_opts(&qemu_numa_opts); \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1793 b/results/classifier/gemma3:12b/hypervisor/1793 new file mode 100644 index 00000000..2fa82821 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1793 @@ -0,0 +1,36 @@ + +getauxval(AT_HWCAP) returns different value under qemu-system-riscv64 and qemu-riscv64 +Description of problem: +I have a test program that checks for the presence of the RISC-V Vector extension (RVV) via getauxval(). + +```c +#include <sys/auxv.h> +#include <stdio.h> + +#define ISA_V_HWCAP (1 << ('v' - 'a')) + +void main() { + unsigned long hw_cap = getauxval(AT_HWCAP); + printf("RVV %s\n", hw_cap & ISA_V_HWCAP ? "detected" : "not found"); +} +``` + +When run inside `qemu-system-riscv64` with a 6.5-rc3 kernel where `CONFIG_RISCV_ISA_V=y` and `CONFIG_RISCV_ISA_V_DEFAULT_ENABLE=y` it correctly shows: + +``` +$ ./hwcap +RVV detected +``` + +However when executed with `qemu-riscv64` it does not return the V bit set: + +``` +$ qemu-riscv64 hwcap +RVV not found +``` +Steps to reproduce: +1. Boot 6.5-rc3 kernel with `CONFIG_RISCV_ISA_V=y` and `CONFIG_RISCV_ISA_V_DEFAULT_ENABLE=y` +2. In guest run test program hwcap (source above) +3. On host run `qemu-riscv64 hwcap` +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1795148 b/results/classifier/gemma3:12b/hypervisor/1795148 new file mode 100644 index 00000000..04f94a10 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1795148 @@ -0,0 +1,14 @@ + +address_space_stw_le_cached: Assertion `addr < cache->len && 2 <= cache ->len - addr' failed + +When running OpenBSD-current as a guest, the following assertion is hit after a few seconds, resulting in the virtual machine to crash: + +``` +qemu-system-x86_64: /build/qemu/src/qemu-3.0.0/include/exec/memory_ldst_cached.inc.h:85: address_space_stw_le_cached: Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +``` + +Host is Arch Linux stable, running on x86_64. + +Qemu version is 3.0.0, installed via the standard Arch Linux package. + +Version 2.12.1 didn't exhibit this behavior. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1797 b/results/classifier/gemma3:12b/hypervisor/1797 new file mode 100644 index 00000000..d0e521b6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1797 @@ -0,0 +1,4 @@ + +RAM-backed snapshotting +Additional information: +And thank you for QEMU! 🙂 diff --git a/results/classifier/gemma3:12b/hypervisor/1798451 b/results/classifier/gemma3:12b/hypervisor/1798451 new file mode 100644 index 00000000..1afa18b7 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1798451 @@ -0,0 +1,34 @@ + +MMX emulation is missing on HVF Acceleration + + +Robs-MacBook-Pro-2:~ robmaskell$ qemu-system-x86_64 --version +QEMU emulator version 3.0.0 + +Host: MacOS - 10.13.6 + Model Name: MacBook Pro + Model Identifier: MacBookPro14,3 + Processor Name: Intel Core i7 + Processor Speed: 2.8 GHz + Number of Processors: 1 + Total Number of Cores: 4 + L2 Cache (per Core): 256 KB + L3 Cache: 6 MB + Memory: 16 GB + +Guest OS: Elementary Linux Loki 0.4.1, patched up to date + +Command used to start QEMU: + +qemu-system-x86_64 \ + -name ElementaryLokiDev \ + -machine pc,accel=hvf \ + -cpu max \ + -smp cpus=2,sockets=2,cores=1,threads=1,maxcpus=2 \ + -numa node,nodeid=0 \ + -numa cpu,node-id=0,socket-id=0 -numa cpu,node-id=0,socket-id=1 \ + -m 8G \ + -vga vmware \ + -hda e4.qcow2 + +Symptoms: Started without the -smp / -numa commands to install the OS, then added -smp / -numa and the machine boots and lscpu reports extra cpu as expected. Restart VM and it hangs on startup. Remove -smp / -numa and machine starts again. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1800993 b/results/classifier/gemma3:12b/hypervisor/1800993 new file mode 100644 index 00000000..8dfa3d57 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1800993 @@ -0,0 +1,10 @@ + +How to Migration VM Built on Qemu Souce Code Installation + +Respected all, + +I followed https://wiki.qemu.org/Hosts/Linux to build qemu from source code. Its installed successfully with Ubuntu 16.04 VM created using VNC server. + +Now, Could you please suggest me how to migrate VM from one host to another?. + +Email: <email address hidden> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1802150 b/results/classifier/gemma3:12b/hypervisor/1802150 new file mode 100644 index 00000000..61479326 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1802150 @@ -0,0 +1,7 @@ + +Guest undefined when destroyed on host after migration + +After a live migration, guest VMs are being undefined from the host they were migrated to after shutdown. I have experienced this at two (2) separate locations on more than one hardware configuration. This happens when utilizing virt-manager to view current allocations on hosts, and virsh on the CLI to migrate guests. When the guest is migrated from one host to another, no errors are thrown, and only lose 1 packet from infinite ping. Shutting guest down *from* the guest OS results in the Guest VM being undefined on the residing host, and XML config lost. If needed, I can provide a recorded session of this happening. + +Thanks, + Dan \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1809 b/results/classifier/gemma3:12b/hypervisor/1809 new file mode 100644 index 00000000..993c2c61 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1809 @@ -0,0 +1,54 @@ + +config machine "virt-6.2" with qemu-system-aarch64,it report "mem is not supported by this machine type" +Description of problem: +When i config the machine with virt-6.2 and config the numa for cpu,it report "mem is not supported by this machine type",but with virt-5.0 it work well,the newer version virt not support it? It is bug or require hardware support?Or compile configure is not correctlly? + +when i create vm,get the error report as follow: + +virsh create test.xml +``` +qemu unexpectedly closed the monitor: qemu-system-aarch64: -chardev socket,id=charmonitor,fd=34,server,nowait: warning: short-form boolean option 'server' deprecated +Please use server=on instead +qemu-system-aarch64: -chardev socket,id=charmonitor,fd=34,server,nowait: warning: short-form boolean option 'nowait' deprecated +Please use wait=off instead +configure accelerator virt-6.2 start +machine init start +2023-08-04T02:17:13.984797Z qemu-system-aarch64: -numa node,nodeid=0,cpus=0-3,mem=8192: Parameter -numa node,mem is not supported by this machine type +Use -numa node,memdev instead + +``` + + +I use qmp command "query-machines" get the result as follow: +``` +{ + "hotpluggable-cpus": true, + "name": "virt-6.2", + ** "numa-mem-supported": false,** + "default-cpu-type": "cortex-a15-arm-cpu", + "cpu-max": 512, + "deprecated": false, + "default-ram-id": "mach-virt.ram", + "alias": "virt" + }, +``` + +I add the code "mc->numa_mem_supported = true;" in the api "virt_machine_6_1_options",it can supoort numa,but i don't know whether it is affected. + +``` +DEFINE_VIRT_MACHINE_AS_LATEST(6, 2) + +static void virt_machine_6_1_options(MachineClass *mc) +{ + VirtMachineClass *vmc = VIRT_MACHINE_CLASS(OBJECT_CLASS(mc)); + + virt_machine_6_2_options(mc); + compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len); + mc->smp_props.prefer_sockets = true; + vmc->no_cpu_topology = true; + **mc->numa_mem_supported = true;** + + /* qemu ITS was introduced with 6.2 */ + vmc->no_tcg_its = true; +} +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1809144 b/results/classifier/gemma3:12b/hypervisor/1809144 new file mode 100644 index 00000000..e09a0452 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1809144 @@ -0,0 +1,36 @@ + +SVM instructions fail with SVME bit enabled + +I was trying to use QEMU/TCG to emulate some stuff that uses SVM. +I know SVM is only partially implemented but I gave it a try anyway. + +I found that if SVM is enabled in the same basic block in which there's a call to VMSAVE/etc, +the call fails as illegal op because the flags don't get updated correctly. + +The pseudocode for the asm I'm running is: + +``` +EFER |= SVME; set the appropriate bit with wrmsr +vmsave +``` + +This is an example of the relevant translate.c code: + +``` + if (!(s->flags & HF_SVME_MASK) || !s->pe) { + goto illegal_op; + } + if (s->cpl != 0) { + gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base); + break; + } +``` + +s->flags doesn't get updated after the wrmsr instruction and so QEMU raises an illegal opcode interrupt. + +A quick fix is to make the tb end after `wrmsr` instructions, but it's an hack afaik. +I'm not too comfortable with QEMU's code, so I don't know what a proper fix would be. + +Cheers, + +thebabush \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1811533 b/results/classifier/gemma3:12b/hypervisor/1811533 new file mode 100644 index 00000000..a2a5e888 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1811533 @@ -0,0 +1,32 @@ + +Unstable Win10 guest with qemu 3.1 + huge pages + hv_stimer + +Host: +Gentoo linux x86_64, kernel 4.20.1 +Qemu 3.1.0 +CPU: Intel i7 6850K +Chipset: X99 + +Guest: +Windows 10 Pro 64bit (1809) +Machine type: pc-q35_3.1 +Hyper-V enlightenments: hv_stimer,hv_reenlightenment,hv_frequencies,hv_vapic,hv_reset,hv_synic,hv_runtime,hv_vpindex,hv_time,hv_relaxed,hv_spinlocks=0x1fff +Memory: 16GB backed by 2MB huge pages + +Issue: +Once guest is started, log gets flooded with: + +qemu-system-x86_64: vhost_region_add_section: Overlapping but not coherent sections at 103000 + +or + +qemu-system-x86_64: vhost_region_add_section:Section rounded to 0 prior to previous 1f000 + +(line endings change) + +and as time goes guest loses network access (virtio-net-pci) and general performance diminishes to extent of freezing applications. + +Observations: +1) problem disappears when hv_stimer is removed +2) problem disappears when memory backing with huge pages is disabled +3) problem disappears when machine type is downgraded to pc-q35_3.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1815263 b/results/classifier/gemma3:12b/hypervisor/1815263 new file mode 100644 index 00000000..46c575f0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1815263 @@ -0,0 +1,103 @@ + +hvf accelerator crashes on quest boot + +Host OS: macOS High Sierra (10.13.6) +MacBook Pro (Retina, Mid 2015) +Processor: 2.8GHz Intel Core i7 +Guest OS: OpenBSD 6.4 install media (install64.iso) +Qemu 3.1.0 release, built with: +./configure --prefix=/usr/local/Cellar/qemu/3.1.0_1 --cc=clang + --host-cc=clang + --disable-bsd-user + --disable-guest-agent + --enable-curses + --enable-libssh2 + --enable-vde + --extra-cflags=-DNCURSES_WIDECHAR=1 + --enable-cocoa + --disable-sdl + --disable-gtk + --enable-hvf + --target-list=x86_64-softmmu + --enable-debug + +I invoke qemu like this: +Last command had exit code: 0 at 22:58 +nwallace@nwallace-ltm3:~ +$ sudo qemu-system-x86_64 -M accel=hvf -boot d -cdrom ~/Downloads/install64.iso +Password: +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +bad size + +Abort trap: 6 +Last command had exit code: 134 at 22:58 +nwallace@nwallace-ltm3:~ +$ + +I ran qemu in lldb to get a stack trace and I get: +Last command had exit code: 0 at 22:54 +nwallace@nwallace-ltm3:~/Downloads +$ sudo lldb -- qemu-system-x86_64 -M accel=hvf -boot d -cdrom /Users/nwallace/Downloads/install64.iso +Password: +(lldb) target create "qemu-system-x86_64" +Current executable set to 'qemu-system-x86_64' (x86_64). +(lldb) settings set -- target.run-args "-M" "accel=hvf" "-boot" "d" "-cdrom" "/Users/nwallace/Downloads/install64.i +so" +(lldb) run +Process 96474 launched: '/usr/local/bin/qemu-system-x86_64' (x86_64) +Process 96474 stopped +* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGUSR2 + frame #0: 0x00007fff5ef0c00a libsystem_kernel.dylib`__sigsuspend + 10 +libsystem_kernel.dylib`__sigsuspend: +-> 0x7fff5ef0c00a <+10>: jae 0x7fff5ef0c014 ; <+20> + 0x7fff5ef0c00c <+12>: movq %rax, %rdi + 0x7fff5ef0c00f <+15>: jmp 0x7fff5ef02b0e ; cerror + 0x7fff5ef0c014 <+20>: retq +Target 0: (qemu-system-x86_64) stopped. +(lldb) process handle SIGUSR1 -n true -p true -s false +NAME PASS STOP NOTIFY +=========== ===== ===== ====== +SIGUSR1 true false true +(lldb) process handle SIGUSR2 -n true -p true -s false +NAME PASS STOP NOTIFY +=========== ===== ===== ====== +SIGUSR2 true false true +(lldb) c +Process 96474 resuming +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +Process 96474 stopped and restarted: thread 9 received signal: SIGUSR2 +<line above repeats about 64 times or so> +Process 96474 stopped and restarted: thread 9 received signal: SIGUSR2 +bad size + +Process 96474 stopped +* thread #9, stop reason = signal SIGABRT + frame #0: 0x00007fff5ef0bb66 libsystem_kernel.dylib`__pthread_kill + 10 +libsystem_kernel.dylib`__pthread_kill: +-> 0x7fff5ef0bb66 <+10>: jae 0x7fff5ef0bb70 ; <+20> + 0x7fff5ef0bb68 <+12>: movq %rax, %rdi + 0x7fff5ef0bb6b <+15>: jmp 0x7fff5ef02ae9 ; cerror_nocancel + 0x7fff5ef0bb70 <+20>: retq +Target 0: (qemu-system-x86_64) stopped. +(lldb) bt +* thread #9, stop reason = signal SIGABRT + * frame #0: 0x00007fff5ef0bb66 libsystem_kernel.dylib`__pthread_kill + 10 + frame #1: 0x00007fff5f0d6080 libsystem_pthread.dylib`pthread_kill + 333 + frame #2: 0x00007fff5ee671ae libsystem_c.dylib`abort + 127 + frame #3: 0x000000010016b6ec qemu-system-x86_64`exec_cmps_single + 400 + frame #4: 0x000000010016ada4 qemu-system-x86_64`exec_cmps + 65 + frame #5: 0x0000000100169aaa qemu-system-x86_64`exec_instruction + 48 + frame #6: 0x0000000100164eb2 qemu-system-x86_64`hvf_vcpu_exec + 2658 + frame #7: 0x000000010005bed6 qemu-system-x86_64`qemu_hvf_cpu_thread_fn + 200 + frame #8: 0x00000001003ee531 qemu-system-x86_64`qemu_thread_start + 107 + frame #9: 0x00007fff5f0d3661 libsystem_pthread.dylib`_pthread_body + 340 + frame #10: 0x00007fff5f0d350d libsystem_pthread.dylib`_pthread_start + 377 + frame #11: 0x00007fff5f0d2bf9 libsystem_pthread.dylib`thread_start + 13 +(lldb) quit +Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] Y +Last command had exit code: 0 at 23:01 +nwallace@nwallace-ltm3:~/Downloads +$ + + +I'm happy to work with someone more knowledgeable to reproduce this issue and provide debugging assistance as I'm able. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1816 b/results/classifier/gemma3:12b/hypervisor/1816 new file mode 100644 index 00000000..63ede946 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1816 @@ -0,0 +1,75 @@ + +Memory size limitation under podman on Apple silicon +Description of problem: +We are using latest MacOS (Ventura) on M2 Ultra with 128Gb RAM (Mac Studio) to run our product Linux aarch64 builds in podman containers. This is cheaper than buying ARM server hardware, and we are not able to use cloud services. + +The issue arises when we try to use the available RAM for the underlying QEMU machine. There seems to be a memory limit which looks like it is in QEMU not podman machine, since that is more of a wrapper in this process. + +The use case is to init a Fedora Linux VM by QEMU which provides a Linux kernel. That kernel is then used to run podman containers. + +When we set the memory limit to 64513Mb the podman machine (VM) start fails with "Error: HV_BAD_ARGUMENT". If we reduce the memory limit to "64512" it works as expected. + +This is an example of how to reproduce: + +` +macstudio:~ build $ podman machine init --cpus="18" --memory="64513" podman-machine-default +Extracting compressed file +Image resized. +Machine init complete +To start your machine run: + +podman machine start + +macstudio:~ build $ podman machine start +Starting machine "podman-machine-default" +Waiting for VM ... +Error: qemu exited unexpectedly with exit code -1, stderr: qemu-system-aarch64: Error: HV_BAD_ARGUMENT + +macstudio:~ build $ podman machine rm --force +macstudio:~ build $ podman machine init --cpus="18" --memory="64512" podman-machine-default +Extracting compressed file +Image resized. +Machine init complete +To start your machine run: + +podman machine start + +macstudio:~ build $ podman machine start +Starting machine "podman-machine-default" +Waiting for VM ... +Mounting volume... /Users:/Users +Mounting volume... /private:/private +Mounting volume... /var/folders:/var/folders + +This machine is currently configured in rootless mode. If your containers +require root permissions (e.g. ports < 1024), or if you run into compatibility +issues with non-podman clients, you can switch using the following command: + +podman machine set --rootful + +API forwarding listening on: /Users/build_ci/.local/share/containers/podman/machine/qemu/podman.sock + +The system helper service is not installed; the default Docker API socket +address can't be used by podman. If you would like to install it run the +following commands: + +sudo /opt/homebrew/Cellar/podman/4.6.0/bin/podman-mac-helper install +podman machine stop; podman machine start + +You can still connect Docker API clients by setting DOCKER_HOST using the +following command in your terminal session: + +export DOCKER_HOST='unix:///Users/build/.local/share/containers/podman/machine/qemu/podman.sock' + +Machine "podman-machine-default" started successfully +macstudio:~ build $ podman machine ls +NAME VM TYPE CREATED LAST UP CPUS MEMORY DISK SIZE +podman-machine-default* qemu About a minute ago Currently running 18 63GiB 100GiB + +` +Steps to reproduce: +1. Initialise the VM with a RAM limit of 64513Mb, then start it. +2. +3. +Additional information: +Feel free to ask for more information. Unfortunately, these machines are our production platform, so further testing will not have a rapid turn around. We are open to taking a machine out of production for testing, it just needs scheduling. diff --git a/results/classifier/gemma3:12b/hypervisor/1816189 b/results/classifier/gemma3:12b/hypervisor/1816189 new file mode 100644 index 00000000..2bb5aad8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1816189 @@ -0,0 +1,27 @@ + +Unable to create or revert snapshots + +With an update to Qemu (3.1.x) I am unable to revert snapshots using virt-manager or virsh. Virtual Machines existing before the update seem to function properly. It is only after creating a new machine that snapshots are misbehaving. I tested spinning up vms of tumbleweed, leap15, and ubuntu 18.04. Each of them had the following issues: + +- With the machine running, live reversions act like they apply, but no changes are actually made. +- With the machine paused, reversion also does not apply. +- With the machine turned off, reversion is not possible. Virsh is unable to find the snapshot, and virt-manager errors out with: + +Error running snapshot 'FreshInstall': internal error: qemu unexpectedly closed the monitor: 2019-01-15T19:19:46.020247Z qemu-system-x86_64: Device 'drive-virtio-disk0' does not have the requested snapshot 'FreshInstall' + +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/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1105, in revert_to_snapshot + self._backend.revertToSnapshot(snap.get_backend()) + File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2024, in revertToSnapshot + if ret == -1: raise libvirtError ('virDomainRevertToSnapshot() failed', dom=self) + +libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2019-01-15T19:19:46.020247Z qemu-system-x86_64: Device 'drive-virtio-disk0' does not have the requested snapshot 'FreshInstall' + +After doing some digging, the error occurs because of the following commit: +d98f26073bebddcd3da0ba1b86c3a34e840c0fb8 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1818 b/results/classifier/gemma3:12b/hypervisor/1818 new file mode 100644 index 00000000..739992ca --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1818 @@ -0,0 +1,21 @@ + +whpx does not work with hyper-v enabled +Description of problem: +I am experiencing issues with the WHPX (Windows Hypervisor Platform Accelerator) hardware acceleration in QEMU on my Windows 10 22h2 system. When I run QEMU with the `-accel whpx` option, I encounter the following problems: + +2. I receive the error message "WHPX: No accelerator found, hr=00000000" followed by "failed to initialize whpx: No space left on device." +Steps to reproduce: +1. Enable the Hyper-V feature on Windows. +2. Install the latest QEMU version +3. Run the QEMU command with the `-accel whpx` option. +Additional information: +- my cpu : intel i7 6500U +- ram : 8 gigabytes +- gpu : intel hd 520 +- drive : C: -> 200 gigabytes, D: -> 1to (c: 109 used, d: 732 used) +- emulated drive -> 50 gigabytes (500mb used) + + + + +(in french sorry) diff --git a/results/classifier/gemma3:12b/hypervisor/1818207 b/results/classifier/gemma3:12b/hypervisor/1818207 new file mode 100644 index 00000000..b79255a2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1818207 @@ -0,0 +1,32 @@ + +[aarch64] VM status remains "running" after it's suspended + +The issue is observed on aarch64 (I didn't check x86) with latest upstream QEMU bits. + +Steps to reproduce: + +1) start guest + +2) suspend guest with this command: + +# echo mem > /sys/power/state + + Check console messages, which should indicate that guest has been suspended. + +3) check guest status through HMP command "info status": + + (qemu) info status + info status + VM status: running + +Note it's "running", which is incorrect. + +QEMU version: + +# qemu-system-aarch64 --version +QEMU emulator version 3.1.50 (v3.1.0-2203-g9403bcc) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +The issue prevents user from resuming a suspended guest through "system_wakeup" HMP command, because QEMU thinks the guest is in running state and does nothing. + +I think the issues occurs because qemu_system_wakeup_request() doesn't get called. It seems the root cause is with ACPI related code. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1818937 b/results/classifier/gemma3:12b/hypervisor/1818937 new file mode 100644 index 00000000..e98218a0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1818937 @@ -0,0 +1,38 @@ + +Crash with HV_ERROR on macOS host + +On macOS host running Windows 10 guest, qemu crashed with error message: Error: HV_ERROR. + +Host: macOS Mojave 10.14.3 (18D109) Late 2014 Mac mini presumably Core i5 4278U. +QEMU: git commit a3e3b0a7bd5de211a62cdf2d6c12b96d3c403560 +QEMU parameter: qemu-system-x86_64 -m 3000 -drive file=disk.img,if=virtio,discard=unmap -accel hvf -soundhw hda -smp 3 + +thread list +Process 56054 stopped + thread #1: tid = 0x2ffec8, 0x00007fff48d0805a vImage`vLookupTable_Planar16 + 970, queue = 'com.apple.main-thread' + thread #2: tid = 0x2ffecc, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #3: tid = 0x2ffecd, 0x00007fff79d715aa libsystem_kernel.dylib`__select + 10 + thread #4: tid = 0x2ffece, 0x00007fff79d71d9a libsystem_kernel.dylib`__sigwait + 10 +* thread #6: tid = 0x2ffed0, 0x00007fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT + thread #7: tid = 0x2ffed1, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #8: tid = 0x2ffed2, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #11: tid = 0x2fff34, 0x00007fff79d6a17a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread' + thread #30: tid = 0x300c04, 0x00007fff79e233f8 libsystem_pthread.dylib`start_wqthread + thread #31: tid = 0x300c16, 0x00007fff79e233f8 libsystem_pthread.dylib`start_wqthread + thread #32: tid = 0x300c17, 0x0000000000000000 + thread #33: tid = 0x300c93, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + + +Crashed thread: + +* thread #6, stop reason = signal SIGABRT + * frame #0: 0x00007fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10 + frame #1: 0x00007fff79e26c1c libsystem_pthread.dylib`pthread_kill + 285 + frame #2: 0x00007fff79cd91c9 libsystem_c.dylib`abort + 127 + frame #3: 0x000000010baa476d qemu-system-x86_64`assert_hvf_ok(ret=<unavailable>) at hvf.c:106 [opt] + frame #4: 0x000000010baa4c8f qemu-system-x86_64`hvf_vcpu_exec(cpu=0x00007f8e5283de00) at hvf.c:681 [opt] + frame #5: 0x000000010b988423 qemu-system-x86_64`qemu_hvf_cpu_thread_fn(arg=0x00007f8e5283de00) at cpus.c:1636 [opt] + frame #6: 0x000000010bd9dfce qemu-system-x86_64`qemu_thread_start(args=<unavailable>) at qemu-thread-posix.c:502 [opt] + frame #7: 0x00007fff79e24305 libsystem_pthread.dylib`_pthread_body + 126 + frame #8: 0x00007fff79e2726f libsystem_pthread.dylib`_pthread_start + 70 + frame #9: 0x00007fff79e23415 libsystem_pthread.dylib`thread_start + 13 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1821595 b/results/classifier/gemma3:12b/hypervisor/1821595 new file mode 100644 index 00000000..7cef52b9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1821595 @@ -0,0 +1,18 @@ + +Failed to emulate MMIO access with EmulatorReturnStatus: 2 + +I have compiled qemu with enable-whpx parameter for Hyper-V Platform API in Mingw64 . When I tried run with Windows 7 iso file I have faced issue with the following problem: +qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 +qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor + + +configuration directives: + +../configure --target-list=x86_64-softmmu,i386-softmmu --enable-lzo\ + --enable-bzip2 --enable-tools --enable-sdl --enable-gtk --enable-hax\ + --enable-vdi --enable-qcow1 --enable-whpx --disable-capstone\ + --disable-werror --disable-stack-protector --prefix="../../QEMU-bin" + + +Qemu command line: +qemu-system-x86_64.exe -m 1024 -cdrom "C:\Users\vmcs\Documents\en_windows_7_home_premium_with_sp1_x86_dvd_u_676701.iso" -display sdl -machine q35 -accel whpx \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1821884 b/results/classifier/gemma3:12b/hypervisor/1821884 new file mode 100644 index 00000000..28e1588a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1821884 @@ -0,0 +1,6 @@ + +Extend uefi-test-tools to report SMBIOS location + +UEFI helper app exposes the pointer to RSDP ACPI table that firmware allocates in guest's RAM +but it doesn't do so for SMBIOS tables. Hence bios table test would skip testing SMBIOS tables +to workaround shortcoming. This bug is a request to expose two new entry point fields (one for SMBIOS 2 and another for SMBIOS 3) so test could check SMBIOS tables when guest is started a with UEFI firmware. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1823 b/results/classifier/gemma3:12b/hypervisor/1823 new file mode 100644 index 00000000..acc1250e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1823 @@ -0,0 +1,12 @@ + +qemu-system-riscv64 Property 'virt-machine.aclint' not found +Description of problem: + +Steps to reproduce: +1. run ./qemu-system-riscv64 -M virt,aclint=on +2. command output: +``` +qemu-system-riscv64: Property 'virt-machine.aclint' not found +``` +Additional information: +The aclint property is registered in the virt_machine_class_init function and depends on the condition tcg_enabled(), but the initialization of tcg_enabled() is later than the call of virt_machine_class_init. This caused the aclint property to never be registered. diff --git a/results/classifier/gemma3:12b/hypervisor/1823831 b/results/classifier/gemma3:12b/hypervisor/1823831 new file mode 100644 index 00000000..ef2ba3b0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1823831 @@ -0,0 +1,13 @@ + +BSD bootloader halts with hypervisor.framework + +Guest: FreeBSD 12.0 Install CD +Host: MacOS 11.14.3 qemu master at 90fb864a7df0a9af677352e94f8225f7b03de922 + +Command arguments: + +qemu-system-x86_64 -m 4000m -cdrom Downloads/FreeBSD-12.0-RELEASE-amd64-bootonly.iso + +When qemu was run with -accel hvf, the bootloader would halt after showing the menu. The bootloader would not respond to any keyboard events. + +Without acceleration option, the bootloader would count down to zero and proceed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1824853 b/results/classifier/gemma3:12b/hypervisor/1824853 new file mode 100644 index 00000000..db075773 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1824853 @@ -0,0 +1,51 @@ + +4.0.0-rc3 crashes with tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed + +I tried to bootstrap and regtested gcc trunk (gcc svn rev 270278, datestamp 20190411) inside my arm64-gentoo installation under qemu-system-aarch64. + +Qemu version was 4.0.0-rc3 and -cpu cortex-a57. Qemu configured with only --target-list=aarch64-softmmu,aarch64-linux-user and compiled using gcc "version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1~16.04)". + +Executable created from gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX.c compiled with -O2 crashed the whole qemu-system. + +To investigate a bit I also manually run +~/gcc/inst/trunk/bin/gcc ~/gcc/src/trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX.c +with different options like: +-O0 -lm -o d0.exe +-O1 -lm -o d1.exe +-O2 -lm -o d2.exe +-O0 -static -lm -o s0.exe +-O1 -static -lm -o s1.exe +-O2 -static -lm -o s2.exe + +So, now I have 6 different arm64 executables created with different optimization levels. O0 and O1 versions run ok. +Three sN.exe static executables I've also tried in qemu user mode (with same -cpu), no issue in user mode. + +And inside qemu-system I can see that +running "d2.exe" (attached) gives: +tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed. + +And running "s2.exe" gives: +tcg/tcg.c:320: set_jmp_reset_offset: Assertion `s->tb_jmp_reset_offset[which] == off' failed. + +It seems like this test is an counter-example for logic that "tcg_ctx->nb_ops < 4000" implies tcg will fit into 16-bit signed size (see tcg_op_buf_full comments). + +Richard's changes in abebf92597186 and 9f754620651d were not enough, translation block must be smaller, or we have to find some proper way to bail out when buffer overflows. +I don't know why this situation is not caught by code_gen_highwater logic in tcg.c + +I've also tried this "bail out" patch + +diff --git a/tcg/tcg.c b/tcg/tcg.c +--- a/tcg/tcg.c ++++ b/tcg/tcg.c +@@ -3949,7 +3949,8 @@ int tcg_gen_code(TCGContext *s, TranslationBlock *tb) + size_t off = tcg_current_code_size(s); + s->gen_insn_end_off[num_insns] = off; + /* Assert that we do not overflow our stored offset. */ +- assert(s->gen_insn_end_off[num_insns] == off); ++ if (s->gen_insn_end_off[num_insns] != off) ++ return -1; + } + num_insns++; + for (i = 0; i < TARGET_INSN_START_WORDS; ++i) { + +But then running "d2.exe" just hangs the whole qemu-system. It seems that when tcg_gen_code return -1 (like in highwater logic mentioned before), we just re-call it again and again. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1825002 b/results/classifier/gemma3:12b/hypervisor/1825002 new file mode 100644 index 00000000..46962e04 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1825002 @@ -0,0 +1,131 @@ + +"qemu: Unexpected FPU mode" since 0c1bbedc10e86ea9366b6af8c5520fafa3266b2f + +This happens every time I attempt to chroot into a gentoo-mips image unless I load the executable via ld.so + +/home (root)# chroot gentoo-mips32r2el /bin/sh +qemu: Unexpected FPU mode +/home (root)# chroot gentoo-mips32r2el /lib/ld-2.19.so /bin/sh +sh-4.2# exit +/home (root)# + +I don't know the underlying cause, but keep in mind that we may lie and claim to have an FPU when our CPU doesn't because of kernel emulation that may not be present in the host kernel. Don't know if that's related. + +I get this with various gentoo-mips stage3 tarballs, but not with OpenWRT. (e.g., https://gentoo.osuosl.org/experimental/mips/stages/mips32r2el/2014) + + + +# emerge --info app-emulation/qemu +Portage 2.3.51 (python 3.6.5-final-0, default/linux/amd64/17.0/desktop/plasma, gcc-8.2.0, glibc-2.27-r6, 4.14.96-gentoo x86_64) +================================================================= + System Settings +================================================================= +System uname: Linux-4.14.96-gentoo-x86_64-AMD_Ryzen_7_2700X_Eight-Core_Processor-with-gentoo-2.6 +KiB Mem: 32890732 total, 3480024 free +KiB Swap: 16777212 total, 10575592 free +Timestamp of repository gentoo: Thu, 11 Apr 2019 06:00:01 +0000 +Head commit of repository gentoo: 66eaaa28926103e690db0699466a274a17ab1979 +sh bash 4.4_p23-r1 +ld GNU ld (Gentoo 2.30 p5) 2.30.0 +distcc 3.3.2 x86_64-pc-linux-gnu [disabled] +ccache version 3.3.4 [disabled] +app-shells/bash: 4.4_p23-r1::gentoo +dev-java/java-config: 2.2.0-r4::gentoo +dev-lang/perl: 5.26.2::gentoo +dev-lang/python: 2.7.15::gentoo, 3.6.5::gentoo +dev-util/ccache: 3.3.4-r1::gentoo +dev-util/cmake: 3.9.6::gentoo +dev-util/pkgconfig: 0.29.2::gentoo +sys-apps/baselayout: 2.6-r1::gentoo +sys-apps/openrc: 0.38.3-r1::gentoo +sys-apps/sandbox: 2.13::gentoo +sys-devel/autoconf: 2.13-r1::gentoo, 2.64-r1::gentoo, 2.69-r4::gentoo +sys-devel/automake: 1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo +sys-devel/binutils: 2.30-r4::gentoo +sys-devel/gcc: 4.9.4::gentoo, 5.4.0-r6::gentoo, 6.4.0-r5::gentoo, 7.3.0-r6::gentoo, 8.1.0-r3::gentoo, 8.2.0-r6::gentoo, 8.3.0::gentoo +sys-devel/gcc-config: 2.0::gentoo +sys-devel/libtool: 2.4.6-r3::gentoo +sys-devel/make: 4.2.1-r4::gentoo +sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers) +sys-libs/glibc: 2.27-r6::gentoo +Repositories: + +gentoo + location: /usr/portage + sync-type: rsync + sync-uri: rsync://rsync.gentoo.org/gentoo-portage + priority: -1000 + sync-rsync-verify-jobs: 1 + sync-rsync-extra-opts: + sync-rsync-verify-metamanifest: yes + sync-rsync-verify-max-age: 24 + +love-local + location: /usr/local/portage + masters: gentoo + priority: 0 + +chaoslab + location: /var/lib/layman/chaoslab + masters: gentoo + priority: 50 + +java + location: /var/lib/layman/java + masters: gentoo + priority: 50 + +steam-overlay + location: /var/lib/layman/steam-overlay + masters: gentoo + priority: 50 + +zugaina + location: /var/lib/layman/zugaina + masters: gentoo + priority: 50 + +ACCEPT_KEYWORDS="amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-march=native -O2 -ggdb3 -pipe" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" +CXXFLAGS="-march=native -O2 -ggdb3 -pipe" +DISTDIR="/mnt/large/distfiles" +EMERGE_DEFAULT_OPTS="-j3 --load-average=17.5 --with-bdeps=y --autounmask=n" +ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs buildpkg candy cgroup compress-build-logs compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles installsources ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch preserve-libs protect-owned sandbox sfperms split-elog split-log splitdebug strict strict-keepdir unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo http://gentoo.mirrors.easynews.com/linux/gentoo/ http://gentoo.osuosl.org/ http://mirrors.rit.edu/gentoo/ http://gentoo.cs.uni.edu/ http://gentoo.osuosl.org/ " +LANG="en_US.utf8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed" +LINGUAS="en en-US en_US" +MAKEOPTS="-j15 --load-average=17" +PKGDIR="/mnt/large/packages" +PORTAGE_COMPRESS="pxz" +PORTAGE_COMPRESS_FLAGS="-9e" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" +PORTAGE_TMPDIR="/tmp" +USE="X a52 aac aacs acl acpi activities aes aio alsa amd64 amr avx avx2 bcache berkdb bluetooth bluray branding bzip2 cairo cdda cddb cdio cdr celt cli consolekit crypt cups cxx d3d9 dbus declarative designer device-mapper dirac directfb dot dri dts dvd dvdr emboss encode exif f16c fam ffmpeg fftw flac fluidsynth fma3 fontconfig fortran fuse gdbm geolocation gif git glamor go gphoto2 gpm gps graphite graphviz gsm gstreamer gtk hardened hddtemp highlight iconv icu ipv6 jpeg jpeg2k kde kerberos kipi kwallet lame latex lcms ldap libass libcaca libnotify libsamplerate libtirpc lm_sensors lto lvm lz4 lzma lzo mad matroska midi mjpeg mmx mmxext mng mono mp3 mp4 mpeg mtp multicall multilib multitarget musepack natspec ncurses netlink networkmanager nfs nls nptl nsplugin ogg openal openexr opengl openh264 openmp openssl opus osmesa pam pango pcap pch pclmul pcre pdf perl pgo phonon plasma playlist png policykit popcnt postgres postproc ppds pulseaudio python qml qt5 rar raw readline samba sasl savedconfig scanner schroedinger sdl seccomp sensors sid smp snappy speex spell spice sqlite sqlite3 squashfs sse sse2 sse3 sse4_1 sse4_2 sse4a ssh ssl ssse3 startup-notification static-libs subversion svg syslog systemtap taglib tcpd theora threads tiff timidity tools tremor truetype tty-helpers twolame udev udisks unicode upnp-av upower usb usbredir utils v4l vaapi valgrind vcdx vdpau vim-syntax virt-network virtio vlc vorbis vpx webdav webp widgets wxwidgets x264 x265 xattr xcb xcomposite xen xine xml xspice xv xvid xvmc zeroconf zlib" ABI_X86="64 32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3" CURL_SSL="openssl" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc coreboot emu multiboot qemu xen" INPUT_DEVICES="keyboard mouse joystick evdev wacom vmmouse" KERNEL="linux" L10N="en en-US en_US" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="AMDGPU ARM BPF NVPTX Mips X86" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" QEMU_SOFTMMU_TARGETS="aarch64 arm armeb i386 hppa m68k microblaze microblazeel mips mips64 mips64el mipsel mipsn32 mipsn32el ppc ppc64 ppc64abi32 ppc64le s390x sparc sparc32plus sparc64 x86_64" QEMU_USER_TARGETS="aarch64 arm armeb i386 hppa m68k microblaze microblazeel mips mips64 mips64el mipsel mipsn32 mipsn32el ppc ppc64 ppc64abi32 ppc64le s390x sparc sparc32plus sparc64 x86_64" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="radeon radeonsi vesa qxl vmware amdgpu" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS + +================================================================= + Package Settings +================================================================= + +app-emulation/qemu-3.1.0-r4::gentoo was built with the following: +USE="aio alsa bzip2 caps curl fdt filecaps gtk jpeg lzo ncurses nfs nls opengl pin-upstream-blobs png pulseaudio python sasl sdl seccomp snappy spice ssh static-user systemtap usb usbredir vde vhost-net virtfs vnc vte xattr xen -accessibility (-capstone) -debug (-glusterfs) -gnutls -infiniband -iscsi -numa -rbd (-selinux) -smartcard (-static) -tci -test -virgl -xfs" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 -python3_5 (-python3_7)" QEMU_SOFTMMU_TARGETS="aarch64 arm hppa i386 m68k microblaze microblazeel mips mips64 mips64el mipsel ppc ppc64 s390x sparc sparc64 x86_64 -alpha -cris -lm32 -moxie -nios2 -or1k -riscv32 -riscv64 -sh4 -sh4eb -tricore -unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="aarch64 arm armeb hppa i386 m68k microblaze microblazeel mips mips64 mips64el mipsel mipsn32 mipsn32el ppc ppc64 ppc64abi32 ppc64le s390x sparc sparc32plus sparc64 x86_64 -aarch64_be -alpha -cris -nios2 -or1k -riscv32 -riscv64 -sh4 -sh4eb -tilegx -xtensa -xtensaeb" + +>>> Attempting to run pkg_info() for 'app-emulation/qemu-3.1.0-r4' +Using: + app-emulation/spice-protocol-0.12.14 + sys-firmware/edk2-ovmf-2017_p20180211 + USE=binary + sys-firmware/ipxe-1.0.0_p20180211 + sys-firmware/seabios-1.11.0 + USE=binary + sys-firmware/sgabios-0.1_pre8-r1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1826599 b/results/classifier/gemma3:12b/hypervisor/1826599 new file mode 100644 index 00000000..4e7f8b3a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1826599 @@ -0,0 +1,19 @@ + +qemu crashes with HV_ERROR with any guest when using HVF on macos + +qemu reliably crashes (after some unknown amount of time) for any guest I've run on macos with HVF acceleration. + +I'm currently running Haiku. After booting and running normally for a few minutes, it abruptly crashes and shows this error on stdout (I'm including the command line arguments): + ++ ISO=haiku-release-anyboot.iso ++ ACCEL='-accel hvf -machine type=q35,accel=hvf' ++ MEM='-m 1G' ++ SMP='-c 2' ++ NET='-device virtio-net,netdev=vmnic -netdev user,id=vmnic' ++ IMG_CD='-cdrom haiku-release-anyboot.iso' ++ IMG_HDD='-device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0' ++ DISPLAY='-usb -device usb-tablet' ++ qemu-system-x86_64 -accel hvf -machine type=q35,accel=hvf -usb -device usb-tablet -m 1G -device virtio-net,netdev=vmnic -netdev user,id=vmnic -device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0 +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +qemu-system-x86_64: Error: HV_ERROR +./qemu-boot.sh: line 19: 67497 Abort trap: 6 qemu-system-x86_64 $ACCEL $CPU $EFI $DISPLAY $MEM $NET $IMG_HDD \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1828 b/results/classifier/gemma3:12b/hypervisor/1828 new file mode 100644 index 00000000..4a394b5f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1828 @@ -0,0 +1,22 @@ + +[v8.0.4 regression] `qemu-system-x86_64: -accel hvf: Unknown Error` +Description of problem: +`-accel hvf` crashes with "Unknown Error". +Regression in v8.0.4. + +The master branch doesn't seem affected. +Steps to reproduce: +v8.0.3: +```console +$ qemu-system-x86_64 -accel hvf +(shows iPXE screen, as expected) +``` + +v8.0.4: +```console +$ qemu-system-x86_64 -accel hvf +qemu-system-x86_64: -accel hvf: Unknown Error +Abort trap: 6 +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1828507 b/results/classifier/gemma3:12b/hypervisor/1828507 new file mode 100644 index 00000000..72a3f3d8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1828507 @@ -0,0 +1,42 @@ + +qemu-system-ppc64 smp crash on manual reset + +Host Environment: + x86_64 Linux v5.0.2 + QEMU emulator version 4.0.50 (v4.0.0-354-g812b835fb4) + SLOF: + Build Date = Jan 14 2019 18:00:39 + FW Version = git-a5b428e1c1eae703 + +Problem: Qemu crash immediately after a manual reset + (this is not the initial reset which launches the guest). + +Steps: + +1. Download Debian ppc64el mini.iso: + http://ftp.debian.org/debian/dists/sid/main/installer-ppc64el/current/images/netboot/mini.iso +2. Run qemu on the host. Ensure that it runs with more than one CPUs. With a single CPU, I was unable + to reproduce the crash. + qemu-system-ppc64 -M pseries -cpu power9 -smp 2 -m 512 -cdrom mini.iso +3. SLOF prints the version info on the serial device, and proceeds to boot. +4. After a few seconds, the GRUB menu appears on the VGA screen. +5. Select one of the install options (I have tested with Default and Expert), and wait + for the Debian's text-mode installer (blue-gray-red) screen to appear. +6. Click Machine->Reset (or enter system_reset on the qemu monitor). +7. Notice that, on the serial device, SLOF has printed the version info. That is, the system + has reset and is attempting to boot again. +8. On the host cmd prompt, qemu dies after printing this fatal error and spewing the + contents of the CPU registers: + + qemu: fatal: Trying to deliver HV exception (MSR) 70 with no HV support + <CPU contents> (See attached out.txt for details) + Aborted (core dumped) + + +The HV exception is either + (a) 70 = HISI, which occurs when NIP contains an outright bogus or inaccessible value, or + (b) 69 = HDSI, which occurs when NIP happens to contain a somewhat saner value, and + the cpu attempts to run the instruction at that address. + +The exception can occur on either of the CPUs. It occurs when qemu is running the SLOF +code. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1830821 b/results/classifier/gemma3:12b/hypervisor/1830821 new file mode 100644 index 00000000..5bbc6406 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1830821 @@ -0,0 +1,8 @@ + +Expose ARCH_CAP_MDS_NO in guest + +Description: + +MDS_NO is bit 5 of ARCH_CAPABILITIES. Expose this bit to guest. + +Target Qemu: 4.1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1832281 b/results/classifier/gemma3:12b/hypervisor/1832281 new file mode 100644 index 00000000..7134389a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1832281 @@ -0,0 +1,52 @@ + +tcg bug master / 4.0.0 v8 operation >>> and |= + +vm guest is linux, executed with tcg +running this Node.js snippet leads to + +$ node +> a = undefined +undefined +> a >>> 0 +4294967295 + +host node +$ node +> a = undefined +undefined +> a >>> 0 +0 + +same with |= + +node +Welcome to Node.js v12.4.0. +Type ".help" for more information. +> let buffer +undefined +> buffer |= 0 +0 + +vm with tcg: + +$ ./out/Release/node --version +v12.4.0 +./out/Release/node -e "let buffer; buffer |= 0; console.log(buffer);" +-1 + + +vm guest is debian x86_64 latest release +vm guest is started with ./x86_64-softmmu/qemu-system-x86_64 -vnc :0 -cdrom debian-9.9.0-amd64-netinst.iso -m 4G -smp cores=6,threads=1,sockets=1 -nic user,hostfwd=tcp:ipv4addr:2233-:22 -cpu qemu64 debian.img + +git tag v4.0.0 and master, commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf, for building qemu-system-x86_64 was used. + +Node.js as compiled on the vm guest (v12.4.0 / master) + + +see also +https://github.com/nodejs/node/issues/19348#issuecomment-500465502 + +I need further assistance to track down the cause of the bug. + +Kind regards +Manuel \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1833668 b/results/classifier/gemma3:12b/hypervisor/1833668 new file mode 100644 index 00000000..9ea0cc03 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1833668 @@ -0,0 +1,28 @@ + +linux-user: Unable to run ARM binaries on Aarch64 + +Download a ARM package from https://packages.debian.org/sid/busybox-static + +Here tested with: busybox-static_1.30.1-4_armel.deb + +$ file busybox.armel +busybox.armel: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=12cf572e016bafa240e113b57b3641e94b837f37, stripped + +$ qemu-aarch64 --version +qemu-aarch64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.14) + +$ qemu-aarch64 busybox.armel +busybox.armel: Invalid ELF image for this architecture + +$ qemu-aarch64 -cpu cortex-a7 busybox.armel +unable to find CPU model 'cortex-a7' + +Also reproduced with commit 33d609990621dea6c7d056c86f707b8811320ac1, +while the aarch64_cpus[] array contains Aarch64 CPUs, the arm_cpus[] array is empty: + +$ gdb -q aarch64-linux-user/qemu-aarch64 +(gdb) p aarch64_cpus +$1 = {{name = 0x1fe4e8 "cortex-a57", initfn = 0x109bc0 <aarch64_a57_initfn>, class_init = 0x0}, {name = 0x1fe508 "cortex-a53", initfn = 0x109a10 <aarch64_a53_initfn>, class_init = 0x0}, {name = 0x1fe518 "cortex-a72", + initfn = 0x109868 <aarch64_a72_initfn>, class_init = 0x0}, {name = 0x218020 "max", initfn = 0x109d70 <aarch64_max_initfn>, class_init = 0x0}, {name = 0x0, initfn = 0x0, class_init = 0x0}} +(gdb) p arm_cpus +$2 = {{name = 0x0, initfn = 0x0, class_init = 0x0}} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1834 b/results/classifier/gemma3:12b/hypervisor/1834 new file mode 100644 index 00000000..b0f126f2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1834 @@ -0,0 +1,185 @@ + +qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed. +Description of problem: + +Steps to reproduce: +1. Run qemu using the provided command line +2. linux kernel boot and qemu crashes at pci bus scan step +3. +Additional information: +``` +SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org +iPXE (http://ipxe.org) 00:02.0 CA00 PCI2.10 PnP PMM+3EFD0CE0+3EF30CE0 CA00 +iPXE (http://ipxe.org) 00:05.0 CB00 PCI2.10 PnP PMM+3EF1FCE0 3EF30CE0 CB00 +Booting from ROM... +[ 0.000000] Linux version 6.1.38-yocto-standard (oe-user@oe-host) (x86_64-poky-linux-gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.40.0.20230620) #1 SMP PREEMPT_DYNAMIC Thu Jul 6 18:52:54 UTC 2023 +[ 0.000000] Command line: console=ttyS0 +[ 0.000000] x86/fpu: x87 FPU will use FXSAVE +[ 0.000000] signal: max sigframe size: 1040 +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003ffdefff] usable +[ 0.000000] BIOS-e820: [mem 0x000000003ffdf000-0x000000003fffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] SMBIOS 3.0.0 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 +[ 0.000000] last_pfn = 0x3ffdf max_arch_pfn = 0x400000000 +[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.000000] found SMP MP-table at [mem 0x000f5b80-0x000f5b8f] +[ 0.000000] ACPI: Early table checksum verification disabled +[ 0.000000] ACPI: RSDP 0x00000000000F59A0 000014 (v00 BOCHS ) +[ 0.000000] ACPI: RSDT 0x000000003FFE238A 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACP 0x000000003FFE217A 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: DSDT 0x000000003FFE0040 00213A (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000003FFE0000 000040 +[ 0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000003FFE0000 000040 +[ 0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: HPET 0x000000003FFE22EE 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: MCFG 0x000000003FFE2326 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: WAET 0x000000003FFE2362 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: Reserving FACP table memory at [mem 0x3ffe217a-0x3ffe226d] +[ 0.000000] ACPI: Reserving DSDT table memory at [mem 0x3ffe0040-0x3ffe2179] +[ 0.000000] ACPI: Reserving FACS table memory at [mem 0x3ffe0000-0x3ffe003f] +[ 0.000000] ACPI: Reserving APIC table memory at [mem 0x3ffe226e-0x3ffe22ed] +[ 0.000000] ACPI: Reserving HPET table memory at [mem 0x3ffe22ee-0x3ffe2325] +[ 0.000000] ACPI: Reserving MCFG table memory at [mem 0x3ffe2326-0x3ffe2361] +[ 0.000000] ACPI: Reserving WAET table memory at [mem 0x3ffe2362-0x3ffe2389] +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.000000] DMA32 [mem 0x0000000001000000-0x000000003ffdefff] +[ 0.000000] Normal empty +[ 0.000000] Device empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff] +[ 0.000000] node 0: [mem 0x0000000000100000-0x000000003ffdefff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000003ffdefff] +[ 0.000000] On node 0, zone DMA: 1 pages in unavailable ranges +[ 0.000000] On node 0, zone DMA: 97 pages in unavailable ranges +[ 0.000000] On node 0, zone DMA32: 33 pages in unavailable ranges +[ 0.000000] ACPI: PM-Timer IO Port: 0x608 +[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.000000] ACPI: Using ACPI (MADT) for SMP configuration information +[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs +[ 0.000000] [mem 0x40000000-0xafffffff] available for PCI devices +[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 +[ 0.000000] percpu: Embedded 52 pages/cpu s173288 r8192 d31512 u1048576 +[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 257759 +[ 0.000000] Kernel command line: console=ttyS0 +[ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear) +[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off +[ 0.000000] Memory: 1002116K/1048052K available (12294K kernel code, 1469K rwdata, 2600K rodata, 1488K init, 2040K bss, 45680K reserved, 0K cma-reserved) +[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 +[ 0.000000] ftrace: allocating 31276 entries in 123 pages +[ 0.000000] ftrace: allocated 123 pages with 6 groups +[ 0.000000] ftrace: allocating 31276 entries in 123 pages +[ 0.000000] ftrace: allocated 123 pages with 6 groups +[ 0.000000] Dynamic Preempt: none +[ 0.000000] rcu: Preemptible hierarchical RCU implementation. +[ 0.000000] rcu: RCU event tracing is enabled. +[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2. +[ 0.000000] Trampoline variant of Tasks RCU enabled. +[ 0.000000] Rude variant of Tasks RCU enabled. +[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. +[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 +[ 0.000000] NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16 +[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. +[ 0.000000] Console: colour VGA+ 80x25 +[ 0.000000] printk: console [ttyS0] enabled +[ 0.000000] ACPI: Core revision 20220331 +[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.020000] APIC: Switch to symmetric I/O mode setup +[ 0.040000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.120000] tsc: Unable to calibrate against PIT +[ 0.120000] tsc: using HPET reference calibration +[ 0.120000] tsc: Detected 2299.960 MHz processor +[ 0.001362] tsc: Marking TSC unstable due to TSCs unsynchronized +[ 0.002851] Calibrating delay loop (skipped), value calculated using timer frequency.. 4599.92 BogoMIPS (lpj=22999600) +[ 0.004441] pid_max: default: 32768 minimum: 301 +[ 0.019780] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) +[ 0.020332] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) +[ 0.078474] process: using AMD E400 aware idle routine +[ 0.079221] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.079631] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.081092] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.082698] Spectre V2 : Mitigation: Retpolines +[ 0.083053] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.083616] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT +[ 0.348864] Freeing SMP alternatives memory: 32K +[ 0.514732] smpboot: CPU0: AMD QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1) +[ 0.536546] cblist_init_generic: Setting adjustable number of callback queues. +[ 0.537604] cblist_init_generic: Setting shift to 1 and lim to 1. +[ 0.538995] cblist_init_generic: Setting shift to 1 and lim to 1. +[ 0.541338] Performance Events: PMU not available due to virtualization, using software events only. +[ 0.548504] rcu: Hierarchical SRCU implementation. +[ 0.548986] rcu: Max phase no-delay instances is 1000. +[ 0.563842] smp: Bringing up secondary CPUs ... +[ 0.583950] x86: Booting SMP configuration: +[ 0.584395] .... node #0, CPUs: #1 +[ 0.802667] smp: Brought up 1 node, 2 CPUs +[ 0.803300] smpboot: Max logical packages: 1 +[ 0.803821] smpboot: Total of 2 processors activated (9202.49 BogoMIPS) +[ 0.864556] devtmpfs: initialized +[ 0.897545] x86/mm: Memory block size: 128MB +[ 0.936982] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 0.938878] futex hash table entries: 512 (order: 3, 32768 bytes, linear) +[ 0.980994] NET: Registered PF_NETLINK/PF_ROUTE protocol family +[ 1.004001] thermal_sys: Registered thermal governor 'step_wise' +[ 1.004143] thermal_sys: Registered thermal governor 'user_space' +[ 1.009528] cpuidle: using governor menu +[ 1.022723] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 1.043717] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 1.050546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 1.060576] PCI: Using configuration type 1 for base access +[ 1.074215] mtrr: your CPUs had inconsistent fixed MTRR settings +[ 1.075157] mtrr: your CPUs had inconsistent variable MTRR settings +[ 1.076043] mtrr: your CPUs had inconsistent MTRRdefType settings +[ 1.076840] mtrr: probably your BIOS does not setup all CPUs. +[ 1.077612] mtrr: corrected configuration. +[ 1.453630] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages +[ 1.454286] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page +[ 1.467152] raid6: skipped pq benchmark and selected sse2x4 +[ 1.467152] raid6: using intx1 recovery algorithm +[ 1.485004] ACPI: Added _OSI(Module Device) +[ 1.485539] ACPI: Added _OSI(Processor Device) +[ 1.485909] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 1.486309] ACPI: Added _OSI(Processor Aggregator Device) +[ 1.578101] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 1.670966] ACPI: Interpreter enabled +[ 1.676848] ACPI: PM: (supports S0 S3 S5) +[ 1.677404] ACPI: Using IOAPIC for interrupt routing +[ 1.683268] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 1.684107] PCI: Using E820 reservations for host bridge windows +[ 1.691382] ACPI: Enabled 2 GPEs in block 00 to 3F +[ 1.828171] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 1.831923] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] +[ 1.839401] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR DPC] +[ 1.843631] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME AER PCIeCapability] +[ 1.867627] PCI host bridge to bus 0000:00 +[ 1.868866] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 1.870044] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 1.870572] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 1.871151] pci_bus 0000:00: root bus resource [mem 0x40000000-0xafffffff window] +[ 1.871719] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 1.872269] pci_bus 0000:00: root bus resource [mem 0x100000000-0x8ffffffff window] +[ 1.873668] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 1.880983] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 1.898659] pci 0000:00:01.0: [1234:1111] type 00 class 0x030000 +qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed. +``` diff --git a/results/classifier/gemma3:12b/hypervisor/1835694 b/results/classifier/gemma3:12b/hypervisor/1835694 new file mode 100644 index 00000000..016f0965 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1835694 @@ -0,0 +1,383 @@ + +hardware-based time keeping + +Hi all, + +I hope you're all doing well. + +As i was looking for a solution for a particular problem in Qemu/KVM +virtualization. + +My issue is that I have a virtual machine that runs well in VMware and when +I migrated that to Qemu/KVM-enabled environment, it didn't work! I figured +out that under VMware hypervisor, VMware supplies CPU TSC and Performance +Counters values to the guest VM with the option +"monitor_control.pseudo_perfctr = TRUE" set the vmx configuration file, +Ref.: https://www.vmware.com/pdf/vmware_timekeeping.pdf + +My question is, is there any similar option in Qemu/KVM-enabled environment +that I can use to get my VM working the same way as in the VMware +environment? + +I almost tried all options in Qemu with regards to CPU but no avail. + +To elaborate more, the VM I'm trying to port under Qemu/KVM environment is +a an old version of Cisco virtual ASA Firewall. The VM image is actually +meant to be run under VMware ESXi and with that +"*monitor_control.pseudo_perfctr += TRUE*" option it can also run in Vware Workstation as well. *Yes, this +option that makes it run under VMware and if it's removed from the +configuration vmx file then the VM boots half way and crashes the same way +it crashes under Qemu*. That dictates it's the option in interest that +needs to be found in Qemu/KVM. I have a copy of this VM in the below link +in case you would like to try its behavior in under VMware. I downloaded it +from a youtube previously to test it out: + +https://drive.google.com/open?id=1SEXws18hoj2sWGk8iFqqH8RpBZsBNpRH + +Once you power on the VM you can telnet to 127.0.0.1 on port 3000 to see +the boot process. If you remove that option i mentioned to you and boot the +VM again you'll see the crashing in process. + + +I've converted that vmdk disk images into Qemu disks "qcow2" format and i +ran them using the below command line on Ubuntu: + +/opt/qemu/bin/qemu-system-x86_64 -L -nographic -device +e1000-82545em,netdev=net0,mac=50:00:00:6a:00:00 -netdev +tap,id=net0,ifname=vunl0_33_0,script=no -device +e1000-82545em,netdev=net1,mac=50:00:00:6a:00:01 -netdev +tap,id=net1,ifname=vunl0_33_1,script=no -device +e1000-82545em,netdev=net2,mac=50:00:00:6a:00:02 -netdev +tap,id=net2,ifname=vunl0_33_2,script=no -device +e1000-82545em,netdev=net3,mac=50:00:00:6a:00:03 -netdev +tap,id=net3,ifname=vunl0_33_3,script=no -machine type=pc-1.0 *-cpu +host,migratable=off,invtsc=on,pmu=on* -m 4096 -hda hda.qcow2 -hdb hdb.qcow2 +-serial telnet:0.0.0.0:3000,server,nowait -monitor +tcp:127.0.0.1:42379,server,nowait +-nographic -display none -enable-kvm + + +Once you power on the VM you can telnet to xx.xx.xx.xx 3000 (where the xx +IP is the Ubuntu machine IP) to see the crashing in process. You may need +to wait for a while for the status messages to appear in the terminal +window. + +I assume it's a cpu issue because in page 9 of the Vmware pdf reference +file; it says there are machine instructions become available when this +option "*monitor_control.pseudo_perfctr = TRUE*" is enabled: + +The following machine instructions then become available: + +Instruction Time Value Returned +rdpmc 0x10000 Physical host TSC +rdpmc 0x10001 Elapsed real time in ns +rdpmc 0x10002 Elapsed apparent time in ns + +Therefore, I used many of the Qemu cpu options such as these: + +-cpu host,migratable=no,+invtsc (ref: https://wiki.qemu.org/ChangeLog/2.1) +-cpu host, tsc-frequency=xxxx (ref: https://lists.gnu.org/archive/ +html/qemu-devel/2017-01/msg03555.html) + -cpu host,migratable=off,invtsc=true,pmu=true + +Not sure if i'm hitting the wrong option! + +The log I'm getting when the VM boots up looks like the following crash +happens at the blue colored log: + +---------------------------------------------------------------------------------------------------------------------------- +Loading... + +Starting image verification +Hash Computation: 100% Done! +Computed Hash SHA2: 63c1e8aa9de3d0c6e738dc91be8e1784 + 5caf64af4cf06cf6a3c5da7200d478dd + 938d380d2b1064f6a349401c7860f50e + cc4eeb98a0ae16c097dbc9447d4d6626 + +Get key records from key storage: Primary, key_store_type: 2 +Embedded Hash SHA2: 63c1e8aa9de3d0c6e738dc91be8e1784 + 5caf64af4cf06cf6a3c5da7200d478dd + 938d380d2b1064f6a349401c7860f50e + cc4eeb98a0ae16c097dbc9447d4d6626 + +The digital signature of the running image verified successfully +Processor memory 3183296512, Reserved memory: 0 + +Total NICs found: 4 +i82545EM rev03 Gigabit Ethernet @ irq10 dev 6 index 03 MAC: 5000.006a.0003 +i82545EM rev03 Gigabit Ethernet @ irq10 dev 5 index 02 MAC: 5000.006a.0002 +i82545EM rev03 Gigabit Ethernet @ irq11 dev 4 index 01 MAC: 5000.006a.0001 +i82545EM rev03 Gigabit Ethernet @ irq11 dev 3 index 00 MAC: 5000.006a.0000 + +Thread Name: lina_flash_init_thread +Page fault: Unknown + r8 0x0000000000000790 + r9 0x00007fff3fa8b000 + r10 0x0000000000000001 + r11 0x000000000210e130 + r12 0x00000000062ebfc0 + r13 0x0000000000010001 + r14 0x0000000000000000 + r15 0x00000000062ebfc0 + rdi 0x00000000062ebfc0 + rsi 0x0000000006c17c20 + rbp 0x00007fff4056f4e0 + rbx 0x00000000062ebfc0 + rdx 0x00007fff40566f10 + rax 0x0000000000000001 + rcx 0x0000000000010001 + rsp 0x00007fff4056f4b0 + rip 0x0000000001581130 + eflags 0x0000000000013202 + csgsfs 0x0000000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 + +Cisco Adaptive Security Appliance Software Version 9.3(1) + +Compiled on Wed 23-Jul-14 18:16 PDT by builders +Hardware: ASAv +Crashinfo collected on 03:42:24.059 UTC Tue Nov 28 2017 + +Traceback: +0: 0x0000000000422118 +1: 0x0000000000422152 +2: 0x0000000000424331 +3: 0x00000000015874a9 +4: 0x00007ffffecd55f0 +5: 0x0000000000558d85 +6: 0x00000000008f5a2b +7: 0x00000000008fd361 +8: 0x0000000000428a15 +Stack dump: base:0x00007fff4056f2e0 size:178, active:178 + entries above '==': return PC preceded by input parameters + entries below '==': local variables followed by saved regs + '==Fn': stack frame n, contains next stack frame + '*': stack pointer at crash + rdi rsi rdx rcx r8 r9 : Arguments 1 through 6 to leaf function + For example: + 0x00007fffeeeeef00: 0x0000000000000009 : arg9 + 0x00007fffeeeeeefc: 0x0000000000000008 : arg8 + 0x00007fffeeeeeef8: 0x0000000000000007 : arg7 + 0x00007fffeeeeeef4: 0x0000000000000abc : return PC + 0x00007fffeeeeeef0: 0x00007fffeeeeef20 ==F2: stack frame F2 + 0x00007fffeeeeeeec: 0x0000000000000def : local variable + 0x00007fffeeeeeee8: 0x0000000000000123 : local variable or saved reg + 0x00007fffeeeeeee4: 0x0000000000000456 : local variable or saved reg + 0x00007fffeeeeeee0: 0x0000000000000789 : local variable or saved reg +0x00007fff4056f870: 0x00007fff4056f7e0 +0x00007fff4056f868: 0x0000000000000000 +0x00007fff4056f860: 0x00000038a11c0123 +0x00007fff4056f858: 0x0000000000000083 +0x00007fff4056f850: 0x00007fff16a864c8 +0x00007fff4056f848: 0x0000000000000000 +0x00007fff4056f840: 0x00000000a11ccdef +0x00007fff4056f838-0x00007fff4056f808: 0x0000000000000000 +0x00007fff4056f800: 0x0000000000429867 +0x00007fff4056f7f8: 0x00007fff4056f860 +0x00007fff4056f7f0: 0x00007fff40567100 +0x00007fff4056f7e8: 0x0000000000000000 +0x00007fff4056f7e0: 0x00000030a11c0123 +0x00007fff4056f7d8: 0x0000000000000083 +0x00007fff4056f7d0: 0x00007fff16a864c8 +0x00007fff4056f7c8: 0x0000000000000000 +0x00007fff4056f7c0: 0x00000000a11ccdef +0x00007fff4056f7b8: 0x0fffffff0fffffff +0x00007fff4056f7b0-0x00007fff4056f7a8: 0x0000000000000000 +0x00007fff4056f7a0: 0x00000000062cc8a0 +0x00007fff4056f798: 0x0000000000000000 +0x00007fff4056f790: 0x00007fff4056f6e0 +0x00007fff4056f788: 0x00007fff4056f758 +0x00007fff4056f780: 0x0000000000000000 +0x00007fff4056f778: 0x00007fff3ff48620 +0x00007fff4056f770-0x00007fff4056f730: 0x0000000000000000 +0x00007fff4056f728: 0x0000000004d14940 +0x00007fff4056f720: 0x000000000041d690 +0x00007fff4056f718: 0x0000000002777640 +0x00007fff4056f710: 0x0000000200010010 +0x00007fff4056f708: 0x0000000006c17d40 +0x00007fff4056f700: 0x00007fff4056f6e0 +0x00007fff4056f6f8: 0x00007fff40150e80 +0x00007fff4056f6f0: 0x000000000638e598 +0x00007fff4056f6e8: 0x00007fff3ff48620 +0x00007fff4056f6e0: 0x00007fff4056f778 +0x00007fff4056f6d8: 0x00000000deadfeed +0x00007fff4056f6d0-0x00007fff4056f6c8: 0x0000000000000000 +0x00007fff4056f6c0: 0x000000000041e1f6 +0x00007fff4056f6b8: 0x00007fff40571fd0 +0x00007fff4056f6b0: 0x00007fff40560cf0 +0x00007fff4056f6a8: 0x0000000000000000 +0x00007fff4056f6a0: 0x000000f0a11c0123 +0x00007fff4056f698: 0x0000000000000143 +0x00007fff4056f690: 0x00007fff16a864c8 +0x00007fff4056f688: 0x0000000000000000 +0x00007fff4056f680: 0x00000000a11ccdef +0x00007fff4056f678-0x00007fff4056f660: 0x0000000000000000 ==F5 +0x00007fff4056f658: 0x000000009abcdef0 +0x00007fff4056f650-0x00007fff4056f5b8: 0x123456789abcdef0 +0x00007fff4056f5b0: 0x0000000000428a01 +0x00007fff4056f5a8: 0x00007fff4056f570 +0x00007fff4056f5a0-0x00007fff4056f590: 0x0000000000000000 +0x00007fff4056f588: 0xffffffffffffdf98 +0x00007fff4056f580: 0x00007fff4056f670 +0x00007fff4056f578: 0x00007fff3ff48370 +0x00007fff4056f570: 0x0000000000000000 +0x00007fff4056f568: 0x0000000000428a15 +0x00007fff4056f560: 0x00007fff4056f670 ==F4 +0x00007fff4056f558: 0x00000000008fd361 +0x00007fff4056f550: 0x00007fff4056f560 ==F3 +0x00007fff4056f548: 0x00000000008f5a2b +0x00007fff4056f540: 0x00007fff4056f550 ==F2 +0x00007fff4056f538: 0x0000000000000000 +0x00007fff4056f530: 0xffffffffffffdf98 +0x00007fff4056f528: 0x00007fff3ff48370 +0x00007fff4056f520: 0x00000000008fba90 +0x00007fff4056f518: 0x00000000008fb908 +0x00007fff4056f510: 0x00007fff4056f550 +0x00007fff4056f508: 0x00000000008fb87e +0x00007fff4056f500: 0x00007fff4056f510 +0x00007fff4056f4f8: 0x0000000000000000 +0x00007fff4056f4f0: 0xffffffffffffdf98 +0x00007fff4056f4e8: 0x0000000000558d85 +0x00007fff4056f4e0: 0x00007fff4056f540 ==F1 +0x00007fff4056f4d8-0x00007fff4056f4d0: 0x0000000000000000 +0x00007fff4056f4c8: 0x0000000000000001 +0x00007fff4056f4c0-0x00007fff4056f4b8: 0x00000000062ebfc0 +0x00007fff4056f4b0: 0x0000000000000000 * +0x00007fff4056f4a8: 0x00000000008fd973 +0x00007fff4056f4a0: 0x00007fff4056f4d0 +0x00007fff4056f498: 0x00007fff40563908 +0x00007fff4056f490: 0x00007fff4056f4d0 +0x00007fff4056f488: 0x00000000009d4b01 +0x00007fff4056f480: 0x00007fff4056f4a0 +0x00007fff4056f478-0x00007fff4056f470: 0x0000000000000000 +0x00007fff4056f468: 0x00007fff418d6390 +0x00007fff4056f460: 0x0000000000000000 +0x00007fff4056f458: 0x000000000201b9f8 +0x00007fff4056f450: 0x00007fff4056f480 +0x00007fff4056f448: 0x00007fff40563908 +0x00007fff4056f440: 0x0000000000000001 +0x00007fff4056f438: 0x00007fff405619a0 +0x00007fff4056f430: 0x00007fff40563908 +0x00007fff4056f428: 0x0000000000000001 +0x00007fff4056f420: 0x0000000000000000 +0x00007fff4056f418: 0x0000000001627125 +0x00007fff4056f410: 0x00007fff4056f450 +0x00007fff4056f408: 0x00007fff3fa8b010 +0x00007fff4056f400: 0x00007fff46505845 +0x00007fff4056f3f8-0x00007fff4056f3c8: 0x0000000000000000 +0x00007fff4056f3c0: 0x0000000000000003 +0x00007fff4056f3b8-0x00007fff4056f3a8: 0x0000000000000000 +0x00007fff4056f3a0: 0x0000000000000240 +0x00007fff4056f398: 0x0000000000000003 +0x00007fff4056f390: 0x0000024446505853 +0x00007fff4056f388-0x00007fff4056f310: 0x0000000000000000 +0x00007fff4056f308: 0x424b7e25fece8fc2 +0x00007fff4056f300: 0x2cc4f98473045e95 +0x00007fff4056f2f8: 0x18fa9b6c57ca0e78 +0x00007fff4056f2f0: 0x081e2a254ab96aa4 +0x00007fff4056f2e8: 0x0000000300000000 + +Begin to dump crashinfo to flash.... + +core0: An internal error occurred. Specifically, a programming assertion +was +violated. Copy the error message exactly as it appears, and get the +output of the show version command and the contents of the configuration +file. Then call your technical support representative. + +assertion "_vf_mode_init" failed: file "vf_api.c", line 136 +core0 same core snap_count=1 signo=6 RIP=7ffffecd43fb + + +----------------------------------------------- +Traceback output aborted. +Flushing first exception frame: +Page fault: Unknown + r8 0x0000000000000790 + r9 0x00007fff3fa8b000 + r10 0x0000000000000001 + r11 0x000000000210e130 + r12 0x00000000062ebfc0 + r13 0x0000000000010001 + r14 0x0000000000000000 + r15 0x00000000062ebfc0 + rdi 0x00000000062ebfc0 + rsi 0x0000000006c17c20 + rbp 0x00007fff4056f4e0 + rbx 0x00000000062ebfc0 + rdx 0x00007fff40566f10 + rax 0x0000000000000001 + rcx 0x0000000000010001 + rsp 0x00007fff4056f4b0 + rip 0x0000000001581130 + eflags 0x0000000000013202 + csgsfs 0x0000000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 +Nested traceback attempted via signal, from: +Abort: Unknown + r8 0x000000000000003c + r9 0x0000000005097a27 + r10 0x00007fff4056de28 + r11 0x0000000000003206 + r12 0x0000000000000001 + r13 0x00007fff4056df80 + r14 0x0000000000000000 + r15 0x0000000000000006 + rdi 0x0000000000000008 + rsi 0x00007fff4056df80 + rbp 0x00007fff4056dfc0 + rbx 0x00007fff29f6b780 + rdx 0x0000000000000010 + rax 0x0000000000000010 + rcx 0xffffffffffffffff + rsp 0x00007fff4056df50 + rip 0x00007ffffecd43fb + eflags 0x0000000000003206 + csgsfs 0x1234000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 + +Cisco Adaptive Security Appliance Software Version 9.3(1) + +Compiled on Wed 23-Jul-14 18:16 PDT by builders +Hardware: ASAv +Crashinfo collected on 03:42:24.059 UTC Tue Nov 28 2017 + +Traceback: +0: 0x0000000000422118 +1: 0x00000000004221f8 +2: 0x000000000042226d +3: 0x0000000001587076 +4: 0x00007ffffecd55f0 +5: 0x00000000015820a0 +6: 0x000000000212d482 +7: 0x000000000139f304 +8: 0x000000000213f315 +9: 0x0000000001460873 +10: 0x0000000001488625 +11: 0x0000000000423e7a +12: 0x00000000004244dc +13: 0x00000000015874a9 +14: 0x00007ffffecd55f0 +15: 0x0000000000558d85 +16: 0x00000000008f5a2b +17: 0x00000000008fd361 +18: 0x0000000000428a15 +----------------------------------------------- +Process shutdown finished +Rebooting..... + +Thanks in advance for your help! :) + +Regards, +Abdullah Alhaddad \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1838913 b/results/classifier/gemma3:12b/hypervisor/1838913 new file mode 100644 index 00000000..6ce7c83f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1838913 @@ -0,0 +1,27 @@ + +Single-step exceptions incorrectly routed to EL1 when ELD is EL2 (TDE = 1) (qemu version 3.1) + +Hi, + +I've been encountering issues with QEMU 3.1 when trying to single-step EL1 code, with ELD = EL2 (MDCR_EL2.TDE = 1). I could test with latest commit in a few hours, if you want. + +EL1 is Aarch64. + +These happen as soon as MDSCR_EL1.SS is set to 1 and ERET is executed: + +1) Single-step exceptions are generated even if they should not be (SPSR_EL2.SS = 0) + +2) Single-step exceptions are routed to EL1 + +Exception return from AArch64 EL2 to AArch64 EL1 PC 0x4000005c +Taking exception 1 [Undefined Instruction] +...from EL1 to EL1 +...with ESR 0x32/0xca000022 +...with ELR 0x4000005c +...to EL1 PC 0x200 PSTATE 0x3c5 + +EC 0x32 (0b110010) is Exception_SoftwareStepLowerEl. + +You can find enclosed minimal code (and resulting .elf) for reproduction. + +qemu-system-aarch64 -nographic -machine virt,virtualization=on -d unimp,int -cpu cortex-a57 -kernel test_hyp.elf \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1838946 b/results/classifier/gemma3:12b/hypervisor/1838946 new file mode 100644 index 00000000..48d88fce --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1838946 @@ -0,0 +1,569 @@ + +qemu 3.10 golang crash + +Encountered below crashes in qemu 3.10 arm +Also have raised the same in golang groups. But seems like in ARM32 hardware, the below commands works fine, only in qemu if crashes. +https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/golang-nuts/1txPOGa4aGc + +Need some pointers to narrow down + +Please see log below. + +$ qemu-arm-static --version +qemu-arm version 3.1.0 (qemu-3.1.0-6.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + + + + +arheneus@bbdee4f6f57d:/sonic/src/telemetry/test$ /usr/local/go/bin/go get -v github.com/Azure/sonic-telemetry/dialout/dialout_client_cli +github.com/openconfig/ygot (download) +github.com/kylelemons/godebug (download) +github.com/openconfig/goyang (download) +SIGSEGV: segmentation violation +PC=0x4512c m=12 sigcode=1 + +goroutine 15 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11c3, 0xf513b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe280a0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 fp=0xf51380 sp=0xf5137c pc=0x88298 +os.(*Process).blockUntilWaitable(0xf80300, 0xf80300, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 fp=0xf51438 sp=0xf51380 pc=0xa94a0 +os.(*Process).wait(0xf80300, 0x13, 0xe6e1d0, 0xeba010) + /usr/local/go/src/os/exec_unix.go:22 +0x2c fp=0xf51470 sp=0xf51438 pc=0xa2d58 +os.(*Process).Wait(0xf80300, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c fp=0xf51484 sp=0xf51470 pc=0xa2494 +os/exec.(*Cmd).Wait(0xe14000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 fp=0xf514bc sp=0xf51484 pc=0xf8620 +os/exec.(*Cmd).Run(0xe14000, 0xd5c720, 0xf30000) + /usr/local/go/src/os/exec/exec.go:309 +0x44 fp=0xf514cc sp=0xf514bc pc=0xf7e1c +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0x116f8e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 fp=0xf515bc sp=0xf514cc pc=0x3549bc +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177d90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c fp=0xf51978 sp=0xf515bc pc=0x3594fc +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177d90, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c fp=0xf51f44 sp=0xf51978 pc=0x35e374 +cmd/go/internal/work.(*Builder).Do.func1(0x1177d90) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 fp=0xf51f84 sp=0xf51f44 pc=0x38287c +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 fp=0xf51fdc sp=0xf51f84 pc=0x382b24 +runtime.goexit() + /usr/local/go/src/runtime/asm_arm.s:867 +0x4 fp=0xf51fdc sp=0xf51fdc pc=0x67f44 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 1 [semacquire]: +sync.runtime_Semacquire(0xdf0078) + /usr/local/go/src/runtime/sema.go:56 +0x2c +sync.(*WaitGroup).Wait(0xdf0070) + /usr/local/go/src/sync/waitgroup.go:130 +0x84 +cmd/go/internal/work.(*Builder).Do(0xd5cf60, 0x1177290) + /usr/local/go/src/cmd/go/internal/work/exec.go:174 +0x304 +cmd/go/internal/work.InstallPackages(0xc82078, 0x1, 0x1, 0xc0e938, 0x1, 0x2) + /usr/local/go/src/cmd/go/internal/work/build.go:506 +0xa88 +cmd/go/internal/get.runGet(0x810d78, 0xc82078, 0x1, 0x1) + /usr/local/go/src/cmd/go/internal/get/get.go:196 +0x1b0 +main.main() + /usr/local/go/src/cmd/go/main.go:219 +0x93c + +goroutine 19 [syscall]: +os/signal.signal_recv(0x0) + /usr/local/go/src/runtime/sigqueue.go:139 +0x130 +os/signal.loop() + /usr/local/go/src/os/signal/signal_unix.go:23 +0x14 +created by os/signal.init.0 + /usr/local/go/src/os/signal/signal_unix.go:29 +0x30 + +goroutine 13 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11ec, 0x10153b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe001e0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xe62840, 0xe62840, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xe62840, 0x1, 0xc0e360, 0xe00160) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xe62840, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0xf8e0b0, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0xf8e0b0, 0xca8060, 0xe6cd00) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0x1015890) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0xfb6210, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:225 +0x11d4 +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0xfb6210, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0xfb6210) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 14 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11ed, 0xe393b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xd280f0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0x115c4e0, 0x115c4e0, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0x115c4e0, 0x1, 0xe78160, 0xd28070) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0x115c4e0, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0x10b8000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0x10b8000, 0xf3e060, 0xf0c000) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0xe39890) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177b80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:225 +0x11d4 +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177b80, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177b80) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 16 [runnable]: +os/exec.(*Cmd).writerDescriptor(0x10b80b0, 0x54bd38, 0xf3e120, 0xf3e0c0, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:257 +0x484 +os/exec.(*Cmd).stderr(0x10b80b0, 0x1112090, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:254 +0xac +os/exec.(*Cmd).Start(0x10b80b0, 0x496701, 0xf3e120) + /usr/local/go/src/os/exec/exec.go:372 +0xa8 +os/exec.(*Cmd).Run(0x10b80b0, 0xf3e120, 0xf0c300) + /usr/local/go/src/os/exec/exec.go:306 +0x1c +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0xf49890) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177ce0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:225 +0x11d4 +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177ce0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177ce0) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 82 [runnable]: +syscall.Syscall(0x3, 0xb, 0x11c2000, 0x8000, 0x0, 0x0, 0x0) + /usr/local/go/src/syscall/asm_linux_arm.s:14 +0x8 +syscall.read(0xb, 0x11c2000, 0x8000, 0x8000, 0x10ea501, 0x0, 0x0) + /usr/local/go/src/syscall/zsyscall_linux_arm.go:732 +0x40 +syscall.Read(0xb, 0x11c2000, 0x8000, 0x8000, 0xdedf9577, 0xe9841d9d, 0xdbb1d24e) + /usr/local/go/src/syscall/syscall_unix.go:172 +0x34 +internal/poll.(*FD).Read(0xd9c140, 0x11c2000, 0x8000, 0x8000, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:165 +0xf0 +os.(*File).read(0xcdc0f0, 0x11c2000, 0x8000, 0x8000, 0x11c3700, 0x1d, 0x6940) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xcdc0f0, 0x11c2000, 0x8000, 0x8000, 0x171d, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +io.copyBuffer(0xe77be000, 0xe88380, 0x54c3f8, 0xcdc0f0, 0x11c2000, 0x8000, 0x8000, 0x443d58, 0x47a900, 0x0, ...) + /usr/local/go/src/io/io.go:402 +0xd8 +io.Copy(0xe77be000, 0xe88380, 0x54c3f8, 0xcdc0f0, 0xe88380, 0x0, 0x40, 0xb) + /usr/local/go/src/io/io.go:364 +0x48 +cmd/go/internal/cache.FileHash(0xe628a0, 0x25, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/cmd/go/internal/cache/hash.go:149 +0x240 +cmd/go/internal/work.(*Builder).fileHash(0xd5cf60, 0xe628a0, 0x25, 0xe628a0, 0x25) + /usr/local/go/src/cmd/go/internal/work/buildid.go:396 +0x24 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177760, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:292 +0x5ec +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177760, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177760) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 83 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11d1, 0xf4d3b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe280b0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xf80330, 0xf80330, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xf80330, 0x1, 0xc7e1b0, 0xe28010) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xf80330, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0x11760b0, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0x11760b0, 0xfc8060, 0xefa800) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0xf278e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177e40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177e40, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177e40) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 84 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11cf, 0xf453b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xeba040) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xf74180, 0xf74180, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xf74180, 0x1, 0x1112070, 0x100e010) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xf74180, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0xfe8000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0xfe8000, 0xe10060, 0xf18000) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0x10878e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177a20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177a20, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177a20) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 85 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11d5, 0xe373b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xeba050) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xf741b0, 0xf741b0, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xf741b0, 0x50, 0xc0e290, 0xe00090) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xf741b0, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0xf8e000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0xf8e000, 0xcb5e00, 0xe6ca00) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0xf2b8e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177ef0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177ef0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177ef0) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 31 [IO wait]: +internal/poll.runtime_pollWait(0xecac29c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xd7c3d4, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xd7c3d4, 0x1040601, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xd7c3c0, 0x1040600, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe78168, 0x1040600, 0x200, 0x200, 0x1040600, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe78168, 0x1040600, 0x200, 0x200, 0xe9d2f000, 0xff667d78, 0x3) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xf3e060, 0x54c3f8, 0xe78168, 0xe9d2f000, 0xf3e060, 0x1b001, 0xcf62b0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xf3e060, 0x54c3f8, 0xe78168, 0x0, 0x0, 0x0, 0x0, 0xcf60c0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xf3e060, 0x54c3f8, 0xe78168, 0x19, 0xfa910, 0xcf6280, 0xf977dc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0xcf6280, 0xf977dc) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x10b8000, 0xd280c0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 30 [IO wait]: +internal/poll.runtime_pollWait(0xecac2dc0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xd7c354, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xd7c354, 0xddc001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xd7c340, 0xddc000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe78148, 0xddc000, 0x200, 0x200, 0xddc000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe78148, 0xddc000, 0x200, 0x200, 0xe9d2f000, 0xff667d78, 0x5) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xf3e000, 0x54c3f8, 0xe78148, 0xe9d2f000, 0xf3e000, 0x1b001, 0xcf62b0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xf3e000, 0x54c3f8, 0xe78148, 0x0, 0x0, 0x0, 0x0, 0xcf6140, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xf3e000, 0x54c3f8, 0xe78148, 0x0, 0xfa910, 0xcf6280, 0xf95fdc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0xcf6280, 0xf95fdc) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x10b8000, 0xd280a0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 37 [IO wait]: +internal/poll.runtime_pollWait(0xecac2f40, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xdc8514, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xdc8514, 0x1040801, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xdc8500, 0x1040800, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc0e338, 0x1040800, 0x200, 0x200, 0x1040800, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc0e338, 0x1040800, 0x200, 0x200, 0xe9d2f000, 0xff669250, 0x3) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xca8000, 0x54c3f8, 0xc0e338, 0xe9d2f000, 0xca8000, 0x16601, 0xc36f54) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xca8000, 0x54c3f8, 0xc0e338, 0x0, 0x0, 0x0, 0x0, 0xd9c0c0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xca8000, 0x54c3f8, 0xc0e338, 0xd9c100, 0xfa910, 0xd9c100, 0xc36fdc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0xd9c100, 0xc36fdc) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xf8e0b0, 0xe00190) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 114 [IO wait]: +internal/poll.runtime_pollWait(0xecac23c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xce8694, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xce8694, 0x108e001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xce8680, 0x108e000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe6e1b8, 0x108e000, 0x200, 0x200, 0x108e000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe6e1b8, 0x108e000, 0x200, 0x200, 0xe9d2f000, 0x4e9d0, 0xc37f18) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0x1024000, 0x54c3f8, 0xe6e1b8, 0xe9d2f000, 0x1024000, 0x1177a01, 0xd5cf98) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0x1024000, 0x54c3f8, 0xe6e1b8, 0x0, 0x0, 0x0, 0x2, 0x0, 0x1, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0x1024000, 0x54c3f8, 0xe6e1b8, 0x1, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xe14000, 0x1042840) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 115 [IO wait]: +internal/poll.runtime_pollWait(0xecac22c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xce8714, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xce8714, 0x108e601, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xce8700, 0x108e600, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe6e1d8, 0x108e600, 0x200, 0x200, 0x108e600, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe6e1d8, 0x108e600, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xd5c720, 0x54c3f8, 0xe6e1d8, 0xe9d2f000, 0xd5c720, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xd5c720, 0x54c3f8, 0xe6e1d8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xd5c720, 0x54c3f8, 0xe6e1d8, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xe14000, 0x1042860) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 116 [IO wait]: +internal/poll.runtime_pollWait(0xecac2c40, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc72214, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc72214, 0xea4201, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc72200, 0xea4200, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc7e190, 0xea4200, 0x200, 0x200, 0xea4200, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc7e190, 0xea4200, 0x200, 0x200, 0xe9d2f000, 0x3e206820, 0x3331203e) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xfc8000, 0x54c3f8, 0xc7e190, 0xe9d2f000, 0xfc8000, 0x61686d01, 0x32336873) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xfc8000, 0x54c3f8, 0xc7e190, 0x0, 0x0, 0x0, 0x34202b20, 0x7361682a, 0x79656b68, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xfc8000, 0x54c3f8, 0xc7e190, 0x70283233, 0x68090a29, 0x72203d20, 0x5f6c746f) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x203d5e20, 0x3e3e2068) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x11760b0, 0xe28040) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 117 [IO wait]: +internal/poll.runtime_pollWait(0xecac2740, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc72294, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc72294, 0xea4001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc72280, 0xea4000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc7e1b8, 0xea4000, 0x200, 0x200, 0xea4000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc7e1b8, 0xea4000, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xfc8060, 0x54c3f8, 0xc7e1b8, 0xe9d2f000, 0xfc8060, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xfc8060, 0x54c3f8, 0xc7e1b8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xfc8060, 0x54c3f8, 0xc7e1b8, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x11760b0, 0xe28070) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 130 [IO wait]: +internal/poll.runtime_pollWait(0xecac25c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc8a114, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc8a114, 0xea4401, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc8a100, 0xea4400, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0x1112058, 0xea4400, 0x200, 0x200, 0xea4400, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0x1112058, 0xea4400, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xe10000, 0x54c3f8, 0x1112058, 0xe9d2f000, 0xe10000, 0x1177d01, 0xd5cf98) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xe10000, 0x54c3f8, 0x1112058, 0x0, 0x0, 0x0, 0x2, 0x0, 0x1, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xe10000, 0x54c3f8, 0x1112058, 0x1, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xfe8000, 0x100e040) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 131 [IO wait]: +internal/poll.runtime_pollWait(0xecac24c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc8a214, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc8a214, 0x1044001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc8a200, 0x1044000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0x1112078, 0x1044000, 0x200, 0x200, 0x1044000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0x1112078, 0x1044000, 0x200, 0x200, 0xe9d2f000, 0xa, 0x2) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xe10060, 0x54c3f8, 0x1112078, 0xe9d2f000, 0xe10060, 0x1, 0x2) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xe10060, 0x54c3f8, 0x1112078, 0x0, 0x0, 0x0, 0xee3e90, 0x27, 0xd2, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xe10060, 0x54c3f8, 0x1112078, 0x2, 0xedca50, 0x2b, 0xbc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xfe8000, 0x100e060) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 132 [IO wait]: +internal/poll.runtime_pollWait(0xecac2240, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xdc82d4, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xdc82d4, 0x1044201, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xdc82c0, 0x1044200, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc0e270, 0x1044200, 0x200, 0x200, 0x1044200, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc0e270, 0x1044200, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xcb5800, 0x54c3f8, 0xc0e270, 0xe9d2f000, 0xcb5800, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xcb5800, 0x54c3f8, 0xc0e270, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xcb5800, 0x54c3f8, 0xc0e270, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0xcc9f80) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xf8e000, 0xe000c0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 133 [IO wait]: +internal/poll.runtime_pollWait(0xecac27c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xdc8354, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xdc8354, 0x1040401, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xdc8340, 0x1040400, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc0e298, 0x1040400, 0x200, 0x200, 0x1040400, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc0e298, 0x1040400, 0x200, 0x200, 0xe9d2f000, 0x0, 0x10b81d0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xcb5e00, 0x54c3f8, 0xc0e298, 0xe9d2f000, 0xcb5e00, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xcb5e00, 0x54c3f8, 0xc0e298, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xcb5e00, 0x54c3f8, 0xc0e298, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xf8e000, 0xe000e0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + + + + +-------------- + +With newer golang version +go version +go version go1.11.9 linux/arm +- show quoted text - +GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build218432843=/tmp/go-build -gno-record-gcc-switches" + + +$ /usr/local/go/bin/go get -v github.com/Azure/sonic-telemetry/dialout/dialout_client_cli +panic: runtime error: invalid memory address or nil pointer dereference +[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x66180] + +goroutine 11fatal error: [malloc deadlock +, panic during panic +[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x66180] + +108033889401^Ifatal error: unexpected signal during runtime execution +stack trace unavailable \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1839325 b/results/classifier/gemma3:12b/hypervisor/1839325 new file mode 100644 index 00000000..272337fe --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1839325 @@ -0,0 +1,72 @@ + +Go programs crash on qemu-sh4 due to issues with atomics + +After #1738545 [1] was fixed, Go applications work fine on qemu-arm but still crash on qemu-sh4. From the backtrace, it looks like an issue with the atomics in qemu-sh4: + +(sid-sh4-sbuild)root@epyc:/# cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} + +(sid-sh4-sbuild)root@epyc:/# gccgo-9 hello.go -o hello +(sid-sh4-sbuild)root@epyc:/# ./hello +panic: ( runtime runtime.errorString) (0x7f74527c,0x80a038) +fatal error: panic on system stack +panic: ( runtime runtime.errorString) (0x7f74527c,0x80a038) +fatal error: panic on system stack + +runtime stack: +runtime..z2finternal..z2fatomic.Load64 + ../../../src/libgo/go/runtime/internal/atomic/atomic.c:37 +runtime_mstart + ../../../src/libgo/runtime/proc.c:596 + +goroutine 1 [running]: + goroutine running on other thread; stack unavailable + +runtime stack: +runtime..z2finternal..z2fatomic.Load64 + ../../../src/libgo/go/runtime/internal/atomic/atomic.c:37 +runtime_mstart + ../../../src/libgo/runtime/proc.c:596 +(sid-sh4-sbuild)root@epyc:/# + +The same sample Go program runs fine on my SH7785LCR SH4 evaluation board: + +root@tirpitz:~> uname -a +Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a GNU/Linux +root@tirpitz:~> cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} + +root@tirpitz:~> gccgo-9 hello.go -o hello +root@tirpitz:~> ./hello +hello world +root@tirpitz:~> + +Please note: In order to be able to reproduce this, one also needs to revert commit 61dedf2af7 [2], otherwise the Go application crashes differently: + +(sid-sh4-sbuild)root@epyc:/# ./hello +Unhandled trap: 0x180 +pc=0x7e5f7f9e sr=0x00000000 pr=0x7ee3d582 fpscr=0x00080004 +spc=0x00000000 ssr=0x00000000 gbr=0x7e590480 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x7e5f7f60 fpul=0x00034f3b +r0=0x008007d4 r1=0x00000000 r2=0xfffe0b2a r3=0x00000002 +r4=0x008006e4 r5=0x00872000 r6=0x00200000 r7=0x00000000 +r8=0x7f7bca7c r9=0x7fffebd4 r10=0x00800480 r11=0x7f7bc0f0 +r12=0x7f7a3fa4 r13=0x008004c0 r14=0x7f7b2238 r15=0x7fffebd0 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@epyc:/# + +> [1] https://bugs.launchpad.net/bugs/1738545 +> [2] https://bugs.launchpad.net/bugs/1796520 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/184 b/results/classifier/gemma3:12b/hypervisor/184 new file mode 100644 index 00000000..ad298170 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/184 @@ -0,0 +1,2 @@ + +SSE CMP ops with 8bit immediate throw sigill with oversized byte diff --git a/results/classifier/gemma3:12b/hypervisor/1841 b/results/classifier/gemma3:12b/hypervisor/1841 new file mode 100644 index 00000000..793049fc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1841 @@ -0,0 +1,13 @@ + +qemu version with 7.2.5 or earlier than 7.2.5 with nvme disk has I/O QID 22 timeout, Aborting errors +Description of problem: +When I use the 7.2.5 version of qemu or versions earlier than 7.2.5 to compile and start the virtual machine, the machine has an nvme disk which is SAMSUNG MZQL23T8HCLS-00B7C and passed through by VFIO. When i use fio to perform pressure test on the nvme disk in vm, dmesg shows message like this nvme nvme0: I/O QID 22 timeout, Aborting, the picture below shows its details. Howerver, when i use 8.0.0 version of qemu to compile and start vm, and using fio to perform pressure test on the nvme disk in vm, it does not have the problem like that. I have using different kernel version, however, the probelem persists, so i think this is not a kernel issue, but a qemu problem. + + +if the irqbalance is running in vm, the problem happens very often, however if the irqbalance is stopped, the problem disappear. + + +Steps to reproduce: +1. using the 7.2.5 or versions earlier than 7.2.5 and start vm which has an nvme disk +2. the nvme disk is passed through by VFIO +3. using FIO to perform pressure test on the nvme disk in vm diff --git a/results/classifier/gemma3:12b/hypervisor/1843254 b/results/classifier/gemma3:12b/hypervisor/1843254 new file mode 100644 index 00000000..2fac22ad --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1843254 @@ -0,0 +1,4 @@ + +arm emulation of HCR.TID3 traps are not implemented + +On ARM (aarch64), HCR_EL2.TID3 [bit18] is supposed to trap ID group 3, which includes the ID_AA64{PFR,DFR,ISAR,MMFR,AFR}*_EL1 registers. However, setting that HCR bit has no effect and accesses to those ID registers are not trapped to EL2 with an EC syndrome value of 0x18. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1843941 b/results/classifier/gemma3:12b/hypervisor/1843941 new file mode 100644 index 00000000..66343a97 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1843941 @@ -0,0 +1,8 @@ + +RBD Namespaces are not supported + +Ceph Nautilus (v14.2.0) introduced the Namespaces concept for RADOS Block Devices. This provides a logical separation within a RADOS Pool for RBD images which enables granular access control. See https://docs.ceph.com/docs/nautilus/releases/nautilus/ for additional details. + +librados and librbd support this, however qemu does not. The rbd man page defines how rbd images within a namespace can be referenced. https://docs.ceph.com/docs/nautilus/man/8/rbd/#image-snap-group-and-journal-specs + +Adding support for RBD namespaces would be beneficial for security and reducing the impact of a hypervisor being compromised and putting an entire Ceph pool or cluster at risk. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1844946 b/results/classifier/gemma3:12b/hypervisor/1844946 new file mode 100644 index 00000000..0f660467 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1844946 @@ -0,0 +1,30 @@ + +macOS HVF broken with WinXP after Aug 21 2018 92d5f1a414 + +I use macOS with own built Qemu to run old XP system that I have migrated from physical machine. My setup is very simple qemu-system-x86_64 with args: +-machine pc,accel=hvf,usb=off,vmport=off +-cpu host +-vga std +-m 2048 +-drive file="$img",format=qcow2,cache=none,detect-zeroes=on +-usb -device usb-tablet + +Unfortunately as soon I enable HVF with first 2 lines WinXP SP3 hangs on boot (famous mup.sys). It works fine in TCG. + +I dived into the code checking the differences between HVF, KVM and HAXM and my analysis is: + +1. Sergio Andres Gomez Del Real b7394c8394 - replaces explicit VMCS_GUEST_INTERRUPTIBILITY checks with hflags/hflags2. + +2. Paolo Bonzini 92d5f1a414 - changes hflags/hflags2 behavior which breaks in the end HVF interrupt handling and makes WinXP unable to boot. NOTE: This does not break I believe KVM and HAXM as they still do explicit check instead what HVF does in 1. That's why it was probably not reported and Qemu macOS users are rather niche ;) + +Reverting 92d5f1a414 makes WinXP boot well and work flawlessly. +Unfortunately b7394c8394 is not easy anymore as too many changes on the way, so it may be not an option. + +This can be reproduced simply by installing /Users/ono/VM/ISO/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso +with HAL as "Standard PC" selectable with F5 on first run. + +I can also provide fresh ~600MB qcow2 image (without activation key entered yet) that is created before boot that fails. No need for full XP installation to test that. + +Nevertheless I would really appreciate Paolo looking into this. +Many thanks for great software, +Adam \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1846392 b/results/classifier/gemma3:12b/hypervisor/1846392 new file mode 100644 index 00000000..b6e4bfe5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1846392 @@ -0,0 +1,65 @@ + +VCPU shutdown request with HAX + +In most scenarios when turning on HAX, QEMU will exit, printing "VCPU shutdown request" to the console. + +This is on Windows 8.1 with Intel HAXM 7.5.2. +QEMU's -version prints v4.1.0-11789-g013a2ecf4f-dirty . +I've used an installer from qemu.weilnetz.de. +The host CPU is an IvyBridge i5 (mobile). + +Some notes: +Win10-1709-PE_Custom.iso is a custom WinPE image I had meant to test using QEMU. It is likely broken and doesn't boot at all. +[Stuck, etc.]: I had given that image almost 2h during which the circle of dots continued to spin. I don't know if it or QEMU did anything of interest at all during that period, but this might indicate long-term stability, sort of. +Win10_1709_German_x32.iso: Stock Win10 1709 32bit ISO I got off a German tech website. I've waited for the install screen to appear. +TinyCore_10-1.iso: TinyCore by Core Project. A 18MB graphical Linux distribution, pretty barren by default. I've generally opened Apps there, the package manager, then shut it down again. +On the one marked [Fx stable], I've gotten Firefox 60.8.0 ESR and visited a couple of websites. (I don't know of any available program that would try to execute exotic CPU instructions in weird combinations to do a proper test.) +Q64 is .\qemu-system-x86_64.exe , substituted for readability (shorter lines). + + +First, those that QEMU seemed to handle well: +Q64 -machine q35 -accel hax +Q64 -machine q35 -cdrom \!S\Win10-1709-PE_Custom.iso +Q64 -machine q35 -cdrom \!S\Win10-1709-PE_Custom.iso -m 4096 [Stuck, etc.] +Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 1920 +Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -cpu max -m 256 [1] +Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -cpu max -m 512 +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu max -serial file:\!S\QEMU_TCL_BUG.log [2] +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax [Fx stable, s.a.] +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Skylake-Client-IBRS +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Icelake-Client-v1 +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Cascadelake-Server-v2 +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Broadwell-v4 +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu IvyBridge-IBRS +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu coreduo +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu pentium +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu base [3] +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu base [4] +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu pentium +Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Icelake-Client-v1 [5] +Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Broadwell-v4 [5] +Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu IvyBridge-v1 [5] +Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu coreduo + + +Then, those that made it print "VCPU shutdown request" repeatedly and quit, immediately or after a couple of seconds at most, except where noted. I put an indication of the number of messages into curly braces. +Q64 -machine q35,accel=hax -cpu max {many} +Q64 -machine q35,accel=hax -cdrom \!S\Win10-1709-PE_Custom.iso +Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax {very many} +Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax -cpu max {very many} +Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax {just two} +Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu max {a couple} +Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Icelake-Client-v1 -accel hax {two} +Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu IvyBridge-v1 -accel hax {two} +Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu pentium -accel hax {three} +.\qemu-system-x86_64.exe -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu coreduo -accel hax {a few} + + +(I have rewritten a couple of commandlines to make them more uniform (changing the placement of parameters and using '-accel hax' instead of '-machine ...,accel=hax').) + +[1]: WinPE boot error, not enough RAM. +[2]: Will cause a kernel BUG: "... \ login[892]: root login on 'tty1' \ BUG: unable to handle kernel paging request at 00010ffa \ ...". See attached file. +[3]: Stuck after "Booting the kernel.", cursor blinks. +[4]: Stuck at blinking console prompt, no input possible. +[5]: According to the printout, TCG doesn't support a bunch of those processor's features that have been requested. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1847232 b/results/classifier/gemma3:12b/hypervisor/1847232 new file mode 100644 index 00000000..8f92d9da --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1847232 @@ -0,0 +1,14 @@ + +qemu TCG in s390x mode issue with calculating HASH + +When using go on s390x on Debian x64 (buster) (host) and debian s390x (sid) (guest) I run into the following problem : + +The following occurs while trying to build a custom project : + +go: <email address hidden>: Get https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod: local error: tls: bad record MAC + +Doing a git bisect I find that this problem only occurs on and after commit 08ef92d556c584c7faf594ff3af46df456276e1b + +Before that commit, all works fine. Past this commit, build always fails. + +Without any proof, It looks like a hash calculation bug related to using z/Arch vector facilities... \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1851664 b/results/classifier/gemma3:12b/hypervisor/1851664 new file mode 100644 index 00000000..9a81514e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1851664 @@ -0,0 +1,7 @@ + +qemu-system-x86_64: "VFIO_MAP_DMA : -28" error when we attache 6 VF's to guest machine + +We are trying to attach 6 VF's to the guest machine on 4.1.1 qemu emulator. +We are observing "VFIO_MAP_DMA : -28" error. + +We are using w-bits=48 bits while lunching VM. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1853826 b/results/classifier/gemma3:12b/hypervisor/1853826 new file mode 100644 index 00000000..0f3ddeed --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1853826 @@ -0,0 +1,108 @@ + +ELF loader fails to load shared object on ThunderX2 running RHEL7 + +Simple test: +hello.c + +include <stdio.h> + +int main(int argc, char* argv[]) +{ + { + printf("Hello World... \n"); + } + return 0; +} + +when compiled with : +*Compiler +https://developer.arm.com/tools-and-software/server-and-hpc/arm-architecture-tools/arm-allinea-studio/download +Arm-Compiler-for-HPC_19.3_RHEL_7_aarch64.tar + +*Running: +1) with -armpl + armclang -armpl hello.c + ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out +2) without flag + armclang hello.c + ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out + +•With Docker image: + CentOS Linux release 7.7.1908 (AltArch) + +*Two different machines: + AArch64, Taishan. tsv110, Kunpeng 920, ARMv8.2-A + AArch64, Taishan 2280, Cortex-A72, ARMv8-A + +*QEMU 4.0 + qemu-aarch64 version 4.1.91 (v4.2.0-rc1) + + +Results: + + + ****Taishan 2280 Cortex-A72 + Running +1)with -armpl flag with and without the docker + WORKS-> Hello World... + -> ldd a.out +ldd a.out +linux-vdso.so.1 => (0x0000ffffbc6a2000) +libamath_generic.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so (0x0000ffffbc544000) +libm.so.6 => /lib64/libm.so.6 (0x0000ffffbc493000) +libastring_generic.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so (0x0000ffffbc472000) libarmflang.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so (0x0000ffffbbfd3000) +libomp.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so (0x0000ffffbbef5000) +librt.so.1 => /lib64/librt.so.1 (0x0000ffffbbed4000) +libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffffbbe9f000) +libarmpl_lp64_generic.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so (0x0000ffffb3306000) +libc.so.6 => /lib64/libc.so.6 (0x0000ffffb3180000) +libstdc++.so.6 => /scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 (0x0000ffffb2f30000) +libgcc_s.so.1 => /scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.so.1 (0x0000ffffb2eff000) +libdl.so.2 => /lib64/libdl.so.2 (0x0000ffffb2ede000) +/lib/ld-linux-aarch64.so.1 (0x0000ffffbc674000) + + +Running +2) without -armpl flag with and without the docker + WORKS -> Hello World... + -> ldd a.out +ldd a.out + linux-vdso.so.1 => (0x0000ffffa6895000) +libastring_generic.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so (0x0000ffffa6846000) +libc.so.6 => /lib64/libc.so.6 (0x0000ffffa66c0000) +/lib/ld-linux-aarch64.so.1 (0x0000ffffa6867000) + + +****Taishan - tsv110 Kunpeng 920 + For Running + +1)with -armpl flag with and without the docker + DOES NOT WORK -> with and without Docker + -> It shows : qemu:handle_cpu_signal received signal outside vCPU + context @ pc=0xffffaaa8844a + -> ldd a.out +ldd a.out +linux-vdso.so.1 => (0x0000ffffad4b0000) +libamath_generic.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so (0x0000ffffad370000) +libm.so.6 => /lib64/libm.so.6 (0x0000ffffad2a0000) +libastring_generic.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so (0x0000ffffad270000) libarmflang.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so (0x0000ffffacdd0000) +libomp.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so (0x0000ffffaccf0000) +librt.so.1 => /lib64/librt.so.1 (0x0000ffffaccc0000) +libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffffacc80000) +libarmpl_lp64_generic.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so (0x0000ffffa40e0000) +libc.so.6 => /lib64/libc.so.6 (0x0000ffffa3f50000) +libstdc++.so.6 => /scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 (0x0000ffffa3d00000) +libgcc_s.so.1 => /scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.so.1 (0x0000ffffa3cc0000) +libdl.so.2 => /lib64/libdl.so.2 (0x0000ffffa3c90000) +/lib/ld-linux-aarch64.so.1 (0x0000ffffad4c0000) + + +Running +2) without -armpl flag with and without the docker + WORKS -> Hello World.. + -> ldd a.out +ldd a.out +linux-vdso.so.1 => (0x0000ffff880c0000) +libastring_generic.so => /scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so (0x0000ffff88080000) +libc.so.6 => /lib64/libc.so.6 (0x0000ffff87ee0000) +/lib/ld-linux-aarch64.so.1 (0x0000ffff880d0000) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1854910 b/results/classifier/gemma3:12b/hypervisor/1854910 new file mode 100644 index 00000000..ee50e39c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1854910 @@ -0,0 +1,4 @@ + +Support VHDX differencing images (ie images with backing) + +The qemu vhdx driver does not support type 2 (differencing) vhdx images (usually stored with file extension .avhdx). This means that any hyperv images with snapshots are not supported by qemu-img. It would be great to be able to convert to a new qcow image from a backing + set of differencing images from hyperv, and/or convert an individual differencing vhdx image to a qcow2 image with a backing file specified. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1855072 b/results/classifier/gemma3:12b/hypervisor/1855072 new file mode 100644 index 00000000..63b2a840 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1855072 @@ -0,0 +1,6 @@ + +ARM: HCR.TVM traps are not implemented + +On AARCH64, setting HCR.TVM to 1 is supposed to trap all writes to CTLR_EL1, TTBR0_EL1, TTBR1_EL1, TCR_EL1, ESR_EL1, FAR_EL1, AFSR0_EL1, AFSR1_EL1, MAIR_EL1, AMAIR_EL1, and CONTEXTIDR_EL1. However, it currently has no effect (QEMU emulator version 4.1.1). + +It is also likely that TRVM will not trap, but, I didn't verify this. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1855617 b/results/classifier/gemma3:12b/hypervisor/1855617 new file mode 100644 index 00000000..97f91b8f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1855617 @@ -0,0 +1,5 @@ + +savevm with hax saves wrong register state + +I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1856335 b/results/classifier/gemma3:12b/hypervisor/1856335 new file mode 100644 index 00000000..525d3b20 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1856335 @@ -0,0 +1,36 @@ + +Cache Layout wrong on many Zen Arch CPUs + +AMD CPUs have L3 cache per 2, 3 or 4 cores. Currently, TOPOEXT seems to always map Cache ass if it was an 4-Core per CCX CPU, which is incorrect, and costs upwards 30% performance (more realistically 10%) in L3 Cache Layout aware applications. + +Example on a 4-CCX CPU (1950X /w 8 Cores and no SMT): + + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>EPYC-IBPB</model> + <vendor>AMD</vendor> + <topology sockets='1' cores='8' threads='1'/> + +In windows, coreinfo reports correctly: + +****---- Unified Cache 1, Level 3, 8 MB, Assoc 16, LineSize 64 +----**** Unified Cache 6, Level 3, 8 MB, Assoc 16, LineSize 64 + +On a 3-CCX CPU (3960X /w 6 cores and no SMT): + + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>EPYC-IBPB</model> + <vendor>AMD</vendor> + <topology sockets='1' cores='6' threads='1'/> + +in windows, coreinfo reports incorrectly: + +****-- Unified Cache 1, Level 3, 8 MB, Assoc 16, LineSize 64 +----** Unified Cache 6, Level 3, 8 MB, Assoc 16, LineSize 64 + + +Validated against 3.0, 3.1, 4.1 and 4.2 versions of qemu-kvm. + +With newer Qemu there is a fix (that does behave correctly) in using the dies parameter: + <qemu:arg value='cores=3,threads=1,dies=2,sockets=1'/> + +The problem is that the dies are exposed differently than how AMD does it natively, they are exposed to Windows as sockets, which means, you can't ever have a machine with more than two CCX (6 cores) as Windows only supports two sockets. (Should this be reported as a separate bug?) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1859418 b/results/classifier/gemma3:12b/hypervisor/1859418 new file mode 100644 index 00000000..7f7a488b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1859418 @@ -0,0 +1,27 @@ + +disk driver with iothread setting hangs live migrations + +Per report raised at https://bugzilla.redhat.com/show_bug.cgi?id=1790093 + +Description of problem: + +A disk driver definition using iothread parameter causes live migration with copy storage to hang during or just before the final ram sync stage. + +Interestingly, having the scsi controller as a separate iothread does not trigger the issue. + +Version-Release number of selected component (if applicable): + +I can reproduce this on centos7 with qemu-ev and with centos 8: + +qemu-kvm-ev-2.12.0-33.1.el7_7.4.x86_64 +qemu-kvm-2.12.0-65.module_el8.0.0+189+f9babebb.5.x86_64 + +Steps to Reproduce: +1. Create a definition with 1 iothread on the disk image: + + <driver name='qemu' type='qcow2' iothread='1' /> + +2. Issue a live migrate request like: virsh migrate --live --copy-storage-all vm qemu+tcp://remote/system +3. Live migrate on source copies storage and then hangs at 80-99%, I guess during the ram copy phase. + +Keeping exactly the same config but without the iothread on the disk driver has successful migrations every time. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1860575 b/results/classifier/gemma3:12b/hypervisor/1860575 new file mode 100644 index 00000000..399dece0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1860575 @@ -0,0 +1,23 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1863025 b/results/classifier/gemma3:12b/hypervisor/1863025 new file mode 100644 index 00000000..71c9106b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1863025 @@ -0,0 +1,47 @@ + +Use-after-free after flush in TCG accelerator + +I believe I found a UAF in TCG that can lead to a guest VM escape. The security +list informed me "This can not be treated as a security issue." and to post it +here. I am looking at the 4.2.0 source code. The issue requires a race and I +will try to describe it in terms of three concurrent threads. + +I am looking +at the 4.2.0 source code. The issue requires a race and I will try to describe +it in terms of three concurrent threads. + +Thread A: + +A1. qemu_tcg_cpu_thread_fn runs work loop +A2. qemu_wait_io_event => qemu_wait_io_event_common => process_queued_cpu_work +A3. start_exclusive critical section entered +A4. do_tb_flush is called, TB memory freed/re-allocated +A5. end_exclusive exits critical section + +Thread B: + +B1. qemu_tcg_cpu_thread_fn runs work loop +B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code +B3. tcg_tb_alloc obtains a new TB + +Thread C: + +C1. qemu_tcg_cpu_thread_fn runs work loop +C2. cpu_exec_step_atomic executes +C3. TB obtained with tb_lookup__cpu_state or tb_gen_code +C4. start_exclusive critical section entered +C5. cpu_tb_exec executes the TB code +C6. end_exclusive exits critical section + +Consider the following sequence of events: + B2 => B3 => C3 (same TB as B2) => A3 => A4 (TB freed) => A5 => B2 => + B3 (re-allocates TB from B2) => C4 => C5 (freed/reused TB now executing) => C6 + +In short, because thread C uses the TB in the critical section, there is no +guarantee that the pointer has not been "freed" (rather the memory is marked as +re-usable) and therefore a use-after-free occurs. + +Since the TCG generated code can be in the same memory as the TB data structure, +it is possible for an attacker to overwrite the UAF pointer with code generated +from TCG. This can overwrite key pointer values and could lead to code +execution on the host outside of the TCG sandbox. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1864955 b/results/classifier/gemma3:12b/hypervisor/1864955 new file mode 100644 index 00000000..0635d3a8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1864955 @@ -0,0 +1,10 @@ + +bundle QEMU installer with HAXM accelerator for Windows + +As you probably know HAXM is an accelerator for Windows. + +https://www.qemu.org/2017/11/22/haxm-usage-windows/ + +Currently it is required to first install QEMU and then install HAXM. + +For a better out of the box user experience on the Windows platform it would be nice if QEMU and HAXM would be installed by the same installer. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1865099 b/results/classifier/gemma3:12b/hypervisor/1865099 new file mode 100644 index 00000000..9e454fc4 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1865099 @@ -0,0 +1,559 @@ + +cannot run x64 based system on x64 host with Intel Haxm + +i am trying to run Windows 10 x64 on Windows 10 x64 host with intel haxm as kernel accelerator, but the system never boots, as far i read the documentation everything should be fine... + +the logs are qemu: + + +` +D:\vm>qemu-system-x86_64 -d guest_errors,out_asm,in_asm,op,op_opt,op_ind,int,exec,cpu,fpu,mmu,pcall,cpu_reset,unimp,page,nochain -cpu core2duo -smp 4 -accel hax -drive file=w10.img,index=0,media=disk,format=raw -cdrom "E:\test\W10x64ProEn-UK.iso" -m 4G -L Bios -usbdevice mouse -usbdevice keyboard -boot menu=on -rtc base=localtime,clock=host -name windows +qemu-system-x86_64: -usbdevice mouse: '-usbdevice' is deprecated, please use '-device usb-...' instead +qemu-system-x86_64: -usbdevice keyboard: '-usbdevice' is deprecated, please use '-device usb-...' instead +HAX is working and emulator runs in fast virt mode. +CPU Reset (CPU 0) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 1) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 2) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 3) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 0) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 1) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 2) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 3) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 1) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 2) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 3) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +` + + +intel haxm (kernel logs): + + +`haxm_warning: Ignored guest CR8 write, val=0x0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored guest CR8 write, val=0x0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0xf +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored guest CR8 write, val=0x0 +haxm_panic: Triple fault +haxm_warning: 4000 VMX_PIN_CONTROLS: 1f +haxm_warning: 4002 VMX_PRIMARY_PROCESSOR_CONTROLS: 969861fe +haxm_warning: 401e VMX_SECONDARY_PROCESSOR_CONTROLS: aa +haxm_warning: 4004 VMX_EXCEPTION_BITMAP: 40000 +haxm_warning: 4006 VMX_PAGE_FAULT_ERROR_CODE_MASK: 0 +haxm_warning: 4008 VMX_PAGE_FAULT_ERROR_CODE_MATCH: 0 +haxm_warning: 400c VMX_EXIT_CONTROLS: 236fff +haxm_warning: 400e VMX_EXIT_MSR_STORE_COUNT: 0 +haxm_warning: 4010 VMX_EXIT_MSR_LOAD_COUNT: 0 +haxm_warning: 4012 VMX_ENTRY_CONTROLS: 93ff +haxm_warning: 4014 VMX_ENTRY_MSR_LOAD_COUNT: 0 +haxm_warning: 4016 VMX_ENTRY_INTERRUPT_INFO: 8 +haxm_warning: 4018 VMX_ENTRY_EXCEPTION_ERROR_CODE: 0 +haxm_warning: 401a VMX_ENTRY_INSTRUCTION_LENGTH: 0 +haxm_warning: 401c VMX_TPR_THRESHOLD: 0 +haxm_warning: 6000 VMX_CR0_MASK: ffffffffe0000020 +haxm_warning: 6002 VMX_CR4_MASK: ffffffffffc8f860 +haxm_warning: 6004 VMX_CR0_READ_SHADOW: 80050031 +haxm_warning: 6006 VMX_CR4_READ_SHADOW: 6a0 +haxm_warning: 400a VMX_CR3_TARGET_COUNT: 0 +haxm_warning: 6008 VMX_CR3_TARGET_VAL_BASE: 0 +haxm_warning: 0000 VMX_VPID: 1 +haxm_warning: 2000 VMX_IO_BITMAP_A: 26e7b9000 +haxm_warning: 2002 VMX_IO_BITMAP_B: 26e7b7000 +haxm_warning: 2004 VMX_MSR_BITMAP: 26e7b6000 +haxm_warning: 2006 VMX_EXIT_MSR_STORE_ADDRESS: 0 +haxm_warning: 2008 VMX_EXIT_MSR_LOAD_ADDRESS: 0 +haxm_warning: 200a VMX_ENTRY_MSR_LOAD_ADDRESS: 0 +haxm_warning: 2010 VMX_TSC_OFFSET: fff957a04c01d76b +haxm_warning: 2012 VMX_VAPIC_PAGE: 0 +haxm_warning: 2014 VMX_APIC_ACCESS_PAGE: 0 +haxm_warning: 201a VMX_EPTP: 1fb1f001e +haxm_warning: 482e VMX_PREEMPTION_TIMER: 0 +haxm_warning: 4400 VMX_INSTRUCTION_ERROR_CODE: 0 +haxm_warning: 4402 VM_EXIT_INFO_REASON: 2 +haxm_warning: 4404 VM_EXIT_INFO_INTERRUPT_INFO: 0 +haxm_warning: 4406 VM_EXIT_INFO_EXCEPTION_ERROR_CODE: 0 +haxm_warning: 4408 VM_EXIT_INFO_IDT_VECTORING: 0 +haxm_warning: 440a VM_EXIT_INFO_IDT_VECTORING_ERROR_CODE: 0 +haxm_warning: 440c VM_EXIT_INFO_INSTRUCTION_LENGTH: 1 +haxm_warning: 440e VM_EXIT_INFO_INSTRUCTION_INFO: 0 +haxm_warning: 6400 VM_EXIT_INFO_QUALIFICATION: 0 +haxm_warning: 6402 VM_EXIT_INFO_IO_ECX: 60 +haxm_warning: 6404 VM_EXIT_INFO_IO_ESI: 1 +haxm_warning: 6406 VM_EXIT_INFO_IO_EDI: 1 +haxm_warning: 6408 VM_EXIT_INFO_IO_EIP: 191f405c +haxm_warning: 640a VM_EXIT_INFO_GUEST_LINEAR_ADDRESS: 0 +haxm_warning: 2400 VM_EXIT_INFO_GUEST_PHYSICAL_ADDRESS: 1ea07ff0 +haxm_warning: 6c16 HOST_RIP: fffff80602e01a73 +haxm_warning: 6c14 HOST_RSP: ffff9b0aae6b74e0 +haxm_warning: 6c00 HOST_CR0: 80050033 +haxm_warning: 6c02 HOST_CR3: 12f527002 +haxm_warning: 6c04 HOST_CR4: 372678 +haxm_warning: 0c02 HOST_CS_SELECTOR: 10 +haxm_warning: 0c06 HOST_DS_SELECTOR: 28 +haxm_warning: 0c00 HOST_ES_SELECTOR: 28 +haxm_warning: 0c08 HOST_FS_SELECTOR: 0 +haxm_warning: 0c0a HOST_GS_SELECTOR: 0 +haxm_warning: 0c04 HOST_SS_SELECTOR: 18 +haxm_warning: 0c0c HOST_TR_SELECTOR: 40 +haxm_warning: 6c06 HOST_FS_BASE: 0 +haxm_warning: 6c08 HOST_GS_BASE: ffffad001d939000 +haxm_warning: 6c0a HOST_TR_BASE: ffffad001d5f7000 +haxm_warning: 6c0c HOST_GDTR_BASE: ffffad001d5f8fb0 +haxm_warning: 6c0e HOST_IDTR_BASE: ffffad001d5f6000 +haxm_warning: 4c00 HOST_SYSENTER_CS: 0 +haxm_warning: 6c10 HOST_SYSENTER_ESP: 0 +haxm_warning: 6c12 HOST_SYSENTER_EIP: 0 +haxm_warning: 681e GUEST_RIP: fffff807167c9370 +haxm_warning: 6820 GUEST_RFLAGS: 10082 +haxm_warning: 681c GUEST_RSP: fffff8071aa67708 +haxm_warning: 6800 GUEST_CR0: 80050031 +haxm_warning: 6802 GUEST_CR3: 1aa000 +haxm_warning: 6804 GUEST_CR4: 26e0 +haxm_warning: 0800 GUEST_ES_SELECTOR: 2b +haxm_warning: 0802 GUEST_CS_SELECTOR: 10 +haxm_warning: 0804 GUEST_SS_SELECTOR: 0 +haxm_warning: 0806 GUEST_DS_SELECTOR: 2b +haxm_warning: 0808 GUEST_FS_SELECTOR: 53 +haxm_warning: 080a GUEST_GS_SELECTOR: 2b +haxm_warning: 080c GUEST_LDTR_SELECTOR: 0 +haxm_warning: 080e GUEST_TR_SELECTOR: 40 +haxm_warning: 4814 GUEST_ES_AR: c0f3 +haxm_warning: 4816 GUEST_CS_AR: 209b +haxm_warning: 4818 GUEST_SS_AR: 1c000 +haxm_warning: 481a GUEST_DS_AR: c0f3 +haxm_warning: 481c GUEST_FS_AR: 40f3 +haxm_warning: 481e GUEST_GS_AR: c0f3 +haxm_warning: 4820 GUEST_LDTR_AR: 1c000 +haxm_warning: 4822 GUEST_TR_AR: 8b +haxm_warning: 6806 GUEST_ES_BASE: 0 +haxm_warning: 6808 GUEST_CS_BASE: 0 +haxm_warning: 680a GUEST_SS_BASE: 0 +haxm_warning: 680c GUEST_DS_BASE: 0 +haxm_warning: 680e GUEST_FS_BASE: 0 +haxm_warning: 6810 GUEST_GS_BASE: fffff807128d3000 +haxm_warning: 6812 GUEST_LDTR_BASE: 0 +haxm_warning: 6814 GUEST_TR_BASE: fffff8071aa5c000 +haxm_warning: 6816 GUEST_GDTR_BASE: fffff8071aa5dfb0 +haxm_warning: 6818 GUEST_IDTR_BASE: fffff8071aa5b000 +haxm_warning: 4800 GUEST_ES_LIMIT: ffffffff +haxm_warning: 4802 GUEST_CS_LIMIT: 0 +haxm_warning: 4804 GUEST_SS_LIMIT: ffffffff +haxm_warning: 4806 GUEST_DS_LIMIT: ffffffff +haxm_warning: 4808 GUEST_FS_LIMIT: 3c00 +haxm_warning: 480a GUEST_GS_LIMIT: ffffffff +haxm_warning: 480c GUEST_LDTR_LIMIT: ffffffff +haxm_warning: 480e GUEST_TR_LIMIT: 67 +haxm_warning: 4810 GUEST_GDTR_LIMIT: 57 +haxm_warning: 4812 GUEST_IDTR_LIMIT: fff +haxm_warning: 2800 GUEST_VMCS_LINK_PTR: ffffffffffffffff +haxm_warning: 2802 GUEST_DEBUGCTL: 0 +haxm_warning: 2804 GUEST_PAT: 0 +haxm_warning: 2806 GUEST_EFER: d01 +haxm_warning: 2808 GUEST_PERF_GLOBAL_CTRL: 0 +haxm_warning: 280a GUEST_PDPTE0: 3380050011 +haxm_warning: 280c GUEST_PDPTE1: 4000 +haxm_warning: 280e GUEST_PDPTE2: 3380050011 +haxm_warning: 2810 GUEST_PDPTE3: 3380050011 +haxm_warning: 681a GUEST_DR7: 400 +haxm_warning: 6822 GUEST_PENDING_DBE: 0 +haxm_warning: 482a GUEST_SYSENTER_CS: 0 +haxm_warning: 6824 GUEST_SYSENTER_ESP: 0 +haxm_warning: 6826 GUEST_SYSENTER_EIP: 0 +haxm_warning: 4828 GUEST_SMBASE: 0 +haxm_warning: 4824 GUEST_INTERRUPTIBILITY: 0 +haxm_warning: 4826 GUEST_ACTIVITY_STATE: 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: ...........hax_teardown_vm +` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1866792 b/results/classifier/gemma3:12b/hypervisor/1866792 new file mode 100644 index 00000000..ac69a567 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1866792 @@ -0,0 +1,62 @@ + +formating vdi-disk over nbd fails + +Hi, +after creating a vdi-image with qemu-vdi and attaching it with qemu-nbd partitioning works fine, but the system hangs up during formating with mkfs.ext4. + +Same procedure with qcow2-image works fine +Tested on Fedora 31 kernel 5.5.7-200.fc31.x86_64 + + +----------------- +#! /bin/sh + +qemu-img create -f qcow2 ~/test.qcow2 32G +#qemu-img version 4.1.1 (qemu-4.1.1-1.fc31) + +modprobe nbd max_part=8 +qemu-nbd --connect=/dev/nbd2 ~/test.qcow2 +#qemu-nbd 4.1.1 (qemu-4.1.1-1.fc31) + +parted -s /dev/nbd2 "mklabel gpt" +parted -s -a optimal /dev/nbd2 "mkpart test ext4 2048 32G " +parted -s -a optimal /dev/nbd2 "p" + +mkfs.ext4 /dev/nbd2p1 +#Format hangs up due to IO errors. +#Tested on Fedora 31, kernel 5.5.7-200.fc31.x86_64 + +mkdir /mnt/test_qcow2 + +mount /dev/nbd2p1 /mnt/test_qcow2 +df -H + +------------------- +#! /bin/sh + +qemu-img create -f vdi ~/test.vdi 32G + +modprobe nbd max_part=8 +qemu-nbd --connect=/dev/nbd4 ~/test.vdi + +parted -s /dev/nbd4 "mklabel gpt" +parted -s -a optimal /dev/nbd4 "mkpart test ext4 2048 32G " +parted -s -a optimal /dev/nbd4 "p" + +mkfs.ext4 /dev/nbd4p1 +#Format hangs up due to IO errors +#Tested on Fedora 31 kernel 5.5.7-200.fc31.x86_64 + +mkdir /mnt/test_vdi + +mount /dev/nbd4p1 /mnt/test_vdi +df -H +---------------------- + + +Kind regards + Eilert + +PS.: There may be a connection to this bug: + +#1661758 qemu-nbd causes data corruption in VDI-format disk images \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1868527 b/results/classifier/gemma3:12b/hypervisor/1868527 new file mode 100644 index 00000000..bdce419c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1868527 @@ -0,0 +1,18 @@ + +alignment may overlap the TLB flags + +Hi, +In QEMU-4.2.0, or git-9b26a610936deaf436af9b7e39e4b7f0a35e4409, alignment may overlap the TLB flags. +For example, the alignment: MO_ALIGN_32, + MO_ALIGN_32 = 5 << MO_ASHIFT, +and the TLB flag: TLB_DISCARD_WRITE +#define TLB_DISCARD_WRITE (1 << (TARGET_PAGE_BITS_MIN - 6)) + +then, in the function "get_alignment_bits", the assert may fail: + +#if defined(CONFIG_SOFTMMU) + /* The requested alignment cannot overlap the TLB flags. */ + tcg_debug_assert((TLB_FLAGS_MASK & ((1 << a) - 1)) == 0); +#endif + +However, the alignment of MO_ALIGN_32 is not used for now, so the assert cannot be triggered in current version. Anyway it seems like a potential conflict. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1871250 b/results/classifier/gemma3:12b/hypervisor/1871250 new file mode 100644 index 00000000..6b999024 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1871250 @@ -0,0 +1,31 @@ + +Failed to create HAX VM + +Hi, + +I'm running the latest (master) of QEMU, though the version doesn't seem to matter - I also checked back to v4.2.0, exactly the same issue. And this isn't about the VM (guest), if I even just try to run, + +> "c:\Program Files\qemu\qemu-system-x86_64.exe" -accel hax + +Basically, just get a window to open, with acceleration enabled ... I get, +Open the vm device error:/dev/hax_vm/vm00, ec:3 +Failed to open vm 0 +Failed to create HAX VM +No accelerator found. + +But I checked - I have installed Intel HAXM, and verified it's running, +> sc query intelhaxm +SERVICE_NAME: intelhaxm + TYPE : 1 KERNEL_DRIVER + STATE : 4 RUNNING + (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) + WIN32_EXIT_CODE : 0 (0x0) + SERVICE_EXIT_CODE : 0 (0x0) + CHECKPOINT : 0x0 + WAIT_HINT : 0x0 + +Just remove the accelerator (-accel hax), and I get a window - so this is related to QEMU being able to contact / use the accelerator. + +Help!?!? + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1871798 b/results/classifier/gemma3:12b/hypervisor/1871798 new file mode 100644 index 00000000..ec2e2a5c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1871798 @@ -0,0 +1,4 @@ + +Fails to start on Windows host without explicit --disable-pie + +Since commit d2cd29e30736afd4a1e8cac3cf4da360bbc65978, which removed the x86 conditional around PIE, QEMU completely fails to start on a Windows host unless --disable-pie is explicitly given at build time. Even just requesting the help text doesn't work. To make testing easier, this can be replicated with Wine. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1877781 b/results/classifier/gemma3:12b/hypervisor/1877781 new file mode 100644 index 00000000..d3b3b1a2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1877781 @@ -0,0 +1,6 @@ + +TCG does not support x2APIC emulation + +This is not a bug so much as a feature request. + +It would be great if there was a pure-software emulation of the x2APIC on x86_64, so that it could be used on systems that don't support such providing a thing on via a host-based solution (e.g., KVM etc). KVM provides this, but that doesn't help if you're working on a machine that doesn't support KVM. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1879 b/results/classifier/gemma3:12b/hypervisor/1879 new file mode 100644 index 00000000..5cab46b9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1879 @@ -0,0 +1,10 @@ + +ARM Cortex-A15 Emulation Not Working +Description of problem: +I want to make a VM with Windows RT 8.1 but it fails because it can't find a file for the to-emulate ARM CPU. +Steps to reproduce: +1. Use virt-manager to make a VM with the ARM architecture. +2. Make sure the emulated CPU is an ARM Cortex-A15. +3. Try installing and making the VM, it will fail with the error. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1879587 b/results/classifier/gemma3:12b/hypervisor/1879587 new file mode 100644 index 00000000..05b82f8a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1879587 @@ -0,0 +1,21 @@ + +Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64 + +I am running into a situation where I have: +- A hypervisor running in EL2, AA64 +- A guest running in EL1, AA32 + +We trap certain accesses to special registers such as DACR (via HCR.TVM). One instruction that is trapped is: + +ee03ef10 -> mcr 15, 0, lr, cr3, cr0, {0} + +The guest is running in SVC mode. So, LR should refer to LR_svc there. LR_svc is mapped to X18 in AA64. So, ESR should reflect that. However, the actual ESR value is: 0xfe00dc0 + +If we decode the 'rt': +>>> (0xfe00dc0 >> 5) & 0x1f +14 + +My understanding is that 14 is incorrect in the context of AA64. rt should be set to 18. The current mode being SVC, LR refers to LR_svc not LR_usr. In other words, the mapping between registers in AA64 and AA32 doesn't seem to be accounted for. I've tested this with Qemu 5.0.0 + +Let me know if that makes sense and if you would like more info. I am also happy to test patches. +Thanks for all the great work on Qemu! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1879672 b/results/classifier/gemma3:12b/hypervisor/1879672 new file mode 100644 index 00000000..2877d208 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1879672 @@ -0,0 +1,13 @@ + +QEMU installer with WHPX support + +People often ask the community to add WHPX support to the QEMU installer for Windows, +but it is impossible due to the license limitations of the WHPX SDK. + +The WinHvEmulation.h and WinHvPlatform.h header files needed are "All +rights reserved". + +However these headers only contain struct definitions and integer constants, +no functional code in macros or inline functions. See: +https://<email address hidden>/msg645815.html +It is questionable whether the headers alone can be considered copyrightable material. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1885247 b/results/classifier/gemma3:12b/hypervisor/1885247 new file mode 100644 index 00000000..4565d6dc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1885247 @@ -0,0 +1,22 @@ + +Build error in Intel 32-bit hosts + +The code base is on master, checked out on Thursday June25th 2020, 0250c595c9d. The build procedure: + +$ mkdir build-gcc +$ cd build-gcc +$ ../configure +$ make + +The build error message is: + + CC x86_64-softmmu/hw/hyperv/hyperv.o + CC x86_64-softmmu/hw/hyperv/hyperv_testdev.o + CC x86_64-softmmu/hw/hyperv/vmbus.o +/home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c: In function ‘gpadl_iter_io’: +/home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c:386:13: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] + p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | off_in_page); + ^ +cc1: all warnings being treated as errors +make[1]: *** [/home/rtrk/Build/qemu-master/rules.mak:69: hw/hyperv/vmbus.o] Error 1 +make: *** [Makefile:527: x86_64-softmmu/all] Error 2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1885553 b/results/classifier/gemma3:12b/hypervisor/1885553 new file mode 100644 index 00000000..fe603248 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1885553 @@ -0,0 +1,11 @@ + +make-check test failed with "Segmentation fault" + +While running the make-check testing on arm architecture the test failed with error: +"kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core dumped)". Apart from that make-install test always passes. +The problem doesn't reproduce in 100% +qemu - from the master branch +RHEL-8 kernel 4.18.0-221.el8.aarch64 +Logfile with an error you can to find in attachment + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1885720 b/results/classifier/gemma3:12b/hypervisor/1885720 new file mode 100644 index 00000000..56fe79e7 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1885720 @@ -0,0 +1,12 @@ + +qemu/migration/postcopy-ram.c:387: bad return expression ? + +qemu/migration/postcopy-ram.c:387:9: style: Non-boolean value returned from function returning bool [returnNonBoolInBooleanFunction] + +Source code is + + return -1; + +but + +bool postcopy_ram_supported_by_host( \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1886208 b/results/classifier/gemma3:12b/hypervisor/1886208 new file mode 100644 index 00000000..fe8a11b0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1886208 @@ -0,0 +1,17 @@ + +[Feature request] Haiku VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +With David Carlier recent work, we can build QEMU on Haiku OS: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01241.html + +To avoid bitrots it would be useful to have a Haiku VM. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1886210 b/results/classifier/gemma3:12b/hypervisor/1886210 new file mode 100644 index 00000000..b9689883 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1886210 @@ -0,0 +1,17 @@ + +[Feature request] Illumnos VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +It would be useful to have a illumos VM to do build testing and avoid regressions. + +Suggested by Thomas Huth: +https://<email address hidden>/msg719202.html \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1886225 b/results/classifier/gemma3:12b/hypervisor/1886225 new file mode 100644 index 00000000..0fc5285c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1886225 @@ -0,0 +1,17 @@ + +[Feature request] Oracle Solaris 11.4 VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +Some people have interest in building QEMU on Solaris: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01429.html + +To help them it would be useful to have a Solaris VM. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1887 b/results/classifier/gemma3:12b/hypervisor/1887 new file mode 100644 index 00000000..01dfec3d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1887 @@ -0,0 +1,10 @@ + +Window VM failed to resume when using GPU passthrough(GVT-d) on Intel platform if add 'hv-stimer' option, seems like it happened after V6.2.0 +Description of problem: +Windows VM failed to be resumed if adding 'hv-stimer' after Qemu v6.2.0. +Steps to reproduce: +1.Set up GVTd env and launch Windows 10 VM as guest; +2. Sleep the Windows VM with Sleep button; +3. Resume Windows VM via telnet to qemu ,e.g.,'telnet 127.0.0.1 2222', then input 'system_wakeup' to resume Windows VM. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1888601 b/results/classifier/gemma3:12b/hypervisor/1888601 new file mode 100644 index 00000000..9ee8b491 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1888601 @@ -0,0 +1,41 @@ + +QEMU v5.1.0-rc0/rc1 hang with nested virtualization + +We're running Kata Containers using QEMU and with v5.1.0rc0 and rc1 have noticed a problem at startup where QEMu appears to hang. We are not seeing this problem on our bare metal nodes and only on a VSI that supports nested virtualization. + +We unfortunately see nothing at all in the QEMU logs to help understand the problem and a hung process is just a guess at this point. + +Using git bisect we first see the problem with... + +--- + +f19bcdfedd53ee93412d535a842a89fa27cae7f2 is the first bad commit +commit f19bcdfedd53ee93412d535a842a89fa27cae7f2 +Author: Jason Wang <email address hidden> +Date: Wed Jul 1 22:55:28 2020 +0800 + + virtio-pci: implement queue_enabled method + + With version 1, we can detect whether a queue is enabled via + queue_enabled. + + Signed-off-by: Jason Wang <email address hidden> + Signed-off-by: Cindy Lu <email address hidden> + Message-Id: <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + Acked-by: Jason Wang <email address hidden> + + hw/virtio/virtio-pci.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- + +Reverting this commit seems to work and prevent the hanging. + +--- + +Here's how kata ends up launching qemu in our environment -- +/opt/kata/bin/qemu-system-x86_64 -name sandbox-849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f -uuid 6bec458e-1da7-4847-a5d7-5ab31d4d2465 -machine pc,accel=kvm,kernel_irqchip -cpu host,pmu=off -qmp unix:/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/qmp.sock,server,nowait -m 4096M,slots=10,maxmem=30978M -device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= -device virtio-serial-pci,disable-modern=true,id=serial0,romfile= -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/console.sock,server,nowait -device virtio-scsi-pci,id=scsi0,disable-modern=true,romfile= -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0,romfile= -device virtserialport,chardev=charch0,id=channel0,name=agent.channel.0 -chardev socket,id=charch0,path=/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/kata.sock,server,nowait -chardev socket,id=char-396c5c3e19e29353,path=/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/vhost-fs.sock -device vhost-user-fs-pci,chardev=char-396c5c3e19e29353,tag=kataShared,romfile= -netdev tap,id=network-0,vhost=on,vhostfds=3:4,fds=5:6 -device driver=virtio-net-pci,netdev=network-0,mac=52:ac:2d:02:1f:6f,disable-modern=true,mq=on,vectors=6,romfile= -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic -daemonize -object memory-backend-file,id=dimm1,size=4096M,mem-path=/dev/shm,share=on -numa node,memdev=dimm1 -kernel /opt/kata/share/kata-containers/vmlinuz-5.7.9-74 -initrd /opt/kata/share/kata-containers/kata-containers-initrd_alpine_1.11.2-6_agent.initrd -append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=4 agent.use_vsock=false scsi_mod.scan=none init=/usr/bin/kata-agent -pidfile /run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/pid -D /run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/qemu.log -smp 2,cores=1,threads=1,sockets=4,maxcpus=4 + +--- \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1892541 b/results/classifier/gemma3:12b/hypervisor/1892541 new file mode 100644 index 00000000..f04a588e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1892541 @@ -0,0 +1,16 @@ + +qemu 5.1 on windows 10 with whpx can not install Windows 7 guest + +Command install and start win7 + +qemu-system-x86_64 -smbios type=1,uuid=e77aacd6-0acb-4a5c-9a83-a80d029b36f1 -smp 2,sockets=1,cores=2,maxcpus=2 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000 -m 8192 ^ +-readconfig pve-q35-4.0.cfg ^ +-device vmgenid,guid=6d4865f5-353e-4cf1-b8ca-f5abbd062736 -device usb-tablet,id=tablet,bus=ehci.0,port=1 -device VGA,id=vga,bus=pcie.0,addr=0x1 ^ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 ^ +-drive file=en_windows_7_ultimate_with_sp1_x64_dvd_u_677332.iso,if=none,id=drive-ide2,media=cdrom,aio=threads ^ +-device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -device ahci,id=ahci0,multifunction=on,bus=pci.0,addr=0x7 ^ +-drive id=drive-sata0,if=none,file=win7.qcow2,format=qcow2,cache=none,aio=native,detect-zeroes=on ^ +-device ide-hd,bus=ahci0.0,drive=drive-sata0,id=sata0,bootindex=100 ^ +-netdev type=tap,id=mynet0,ifname=tap1,script=no,downscript=no ^ +-device e1000,netdev=mynet0,mac=52:55:00:d1:55:10,bus=pci.0,addr=0x12,id=net0,bootindex=300 ^ +-machine type=q35,accel=whpx \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1893 b/results/classifier/gemma3:12b/hypervisor/1893 new file mode 100644 index 00000000..941f49f1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1893 @@ -0,0 +1,14 @@ + +assert on savevm +Description of problem: + +Steps to reproduce: +1. launch as above (n.b. qemu-img command: qemu-img create -f qcow2 rootfs.qcow2 60G +2. from qemu monitor: savevm test +3. On stderr + +``` +Assertion failed: (qemu_get_current_aio_context() == qemu_get_aio_context()), function bdrv_poll_co, file block-gen.h, line 43. +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1893040 b/results/classifier/gemma3:12b/hypervisor/1893040 new file mode 100644 index 00000000..516fc768 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1893040 @@ -0,0 +1,17 @@ + + External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues + +We are observing issue while building go-runner image and we suspect it is due to QEMU version being used. As referred in below issue: +https://github.com/golang/go/issues/40949 + +We tried to build go-runner image using go1.15 and register QEMU (docker run --rm --privileged multiarch/qemu-user-static@sha256:c772ee1965aa0be9915ee1b018a0dd92ea361b4fa1bcab5bbc033517749b2af4 --reset -p yes) as mentioned in PR https://github.com/kubernetes/release/pull/1499. We observed below failure during build: + +------------------------------------------------------------------------------------------------------------- +ERROR: executor failed running [/bin/sh -c CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner ${package}]: buildkit-runc did not terminate successfully +------ + > [builder 7/7] RUN CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner .: +------ +failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner ${package}]: buildkit-runc did not terminate successfully +Makefile:52: recipe for target 'container' failed +make: *** [container] Error 1 +------------------------------------------------------------------------------------------------------------- \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1894029 b/results/classifier/gemma3:12b/hypervisor/1894029 new file mode 100644 index 00000000..a17150e8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1894029 @@ -0,0 +1,40 @@ + +qemu-i386 malloc error + +Hi!I use qemu-i386-static on 64 bit machines.And memory request succeeded, but the pointer is wrong. +This is my test program: + +#include <stdint.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +int main(int argc, char **argv) +{ + void *pa=0,*pb=0,*pc=0,*pd=0; + pa = malloc(sizeof(uint32_t)); + pb = malloc(sizeof(uint32_t)); + pc = malloc(4); + pd = malloc(4); + printf("pa: 0x%x\n",pa); + printf("pb: 0x%x\n",pb); + printf("pc: 0x%x\n",pc); + printf("pd: 0x%x\n",pd); + printf("uint32_t:%d\n",sizeof(uint32_t)); + free(pa); + free(pb); + free(pc); + free(pd); + return 0; +} + +And it is wrong: + +pa: 0x400051a0 +pb: 0x400051b0 +pc: 0x400051c0 +pd: 0x400051d0 +uint32_t:4 + +Why did I apply for 4 bytes of space, but the pointer only increased by 2 bytes?? +Is it a BUG?? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1894804 b/results/classifier/gemma3:12b/hypervisor/1894804 new file mode 100644 index 00000000..54a37f71 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1894804 @@ -0,0 +1,269 @@ + +Second DEVICE_DELETED event missing during virtio-blk disk device detach + +We are in the process of moving OpenStack CI across to use 20.04 Focal as the underlying OS and encountering the following issue in any test attempting to detach disk devices from running QEMU instances. + +We can see a single DEVICE_DELETED event raised to libvirtd for the /machine/peripheral/virtio-disk1/virtio-backend device but we do not see a second event for the actual disk. As a result the device is still marked as present in libvirt but QEMU reports it as missing in subsequent attempts to remove the device. + +The following log snippets can also be found in the following pastebin that's slightly easier to gork: + +http://paste.openstack.org/show/797564/ + +https://review.opendev.org/#/c/746981/ libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION + +https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260 nova-ceph-multistore + +https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260/log/controller/logs/dpkg-l.txt + +ii libvirt-daemon 6.0.0-0ubuntu8.3 amd64 Virtualization daemon +ii libvirt-daemon-driver-qemu 6.0.0-0ubuntu8.3 amd64 Virtualization daemon QEMU connection driver +ii libvirt-daemon-system 6.0.0-0ubuntu8.3 amd64 Libvirt daemon configuration files +ii libvirt-daemon-system-systemd 6.0.0-0ubuntu8.3 amd64 Libvirt daemon configuration files (systemd) +ii libvirt-dev:amd64 6.0.0-0ubuntu8.3 amd64 development files for the libvirt library +ii libvirt0:amd64 6.0.0-0ubuntu8.3 amd64 library for interfacing with different virtualization systems +[..] +ii qemu-block-extra:amd64 1:4.2-3ubuntu6.4 amd64 extra block backend modules for qemu-system and qemu-utils +ii qemu-slof 20191209+dfsg-1 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries +ii qemu-system-arm 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-data 1:4.2-3ubuntu6.4 all QEMU full system emulation (data files) +ii qemu-system-mips 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (miscellaneous) +ii qemu-system-ppc 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (ppc) +ii qemu-system-s390x 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (s390x) +ii qemu-system-sparc 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:4.2-3ubuntu6.4 amd64 QEMU utilities + +https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260/log/controller/logs/libvirt/qemu/instance-0000003a_log.txt + +2020-09-07 19:29:55.021+0000: starting up libvirt version: 6.0.0, package: 0ubuntu8.3 (Marc Deslauriers <email address hidden> Thu, 30 Jul 2020 06:40:28 -0400), qemu version: 4.2.0Debian 1:4.2-3ubuntu6.4, kernel: 5.4.0-45-generic, hostname: ubuntu-focal-ovh-bhs1-0019682147 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ +HOME=/var/lib/libvirt/qemu/domain-86-instance-0000003a \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-86-instance-0000003a/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-86-instance-0000003a/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-86-instance-0000003a/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=instance-0000003a,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-86-instance-0000003a/master-key.aes \ +-machine pc-i440fx-4.2,accel=tcg,usb=off,dump-guest-core=off \ +-cpu qemu64 \ +-m 128 \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 0d59f238-daef-40d4-adf9-a4fa24c35231 \ +-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=21.1.0,serial=0d59f238-daef-40d4-adf9-a4fa24c35231,uuid=0d59f238-daef-40d4-adf9-a4fa24c35231,family=Virtual Machine' \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=39,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-object secret,id=libvirt-3-storage-secret0,data=zT+XibedVJZM2du1+PXpIXHMVJ9a0pVcKihOtCGwlB0=,keyid=masterKey0,iv=536Lfw+nsyvDhFBTOQG4zA==,format=base64 \ +-blockdev '{"driver":"rbd","pool":"vms","image":"0d59f238-daef-40d4-adf9-a4fa24c35231_disk","server":[{"host":"158.69.70.115","port":"6789"}],"user":"cinder","auth-client-required":["cephx","none"],"key-secret":"libvirt-3-storage-secret0","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-3-storage"}' \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-object secret,id=libvirt-2-storage-secret0,data=SO9AgCCTvkBBMYHZe+LVzoCF4GUNgvBtkFwRRIji7WI=,keyid=masterKey0,iv=MzGu/h2Api4mMG9lL8hvdg==,format=base64 \ +-blockdev '{"driver":"rbd","pool":"volumes","image":"volume-04dd79b2-3c05-4492-b1d7-7969d24df768","server":[{"host":"158.69.70.115","port":"6789"}],"user":"cinder","auth-client-required":["cephx","none"],"key-secret":"libvirt-2-storage-secret0","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"discard":"unmap","cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=libvirt-2-format,id=virtio-disk1,write-cache=on,serial=04dd79b2-3c05-4492-b1d7-7969d24df768 \ +-object secret,id=libvirt-1-storage-secret0,data=lhbR9+ewiXiaf3dKoQWP3bk6hlLMLRXnbhh9ZkjZ9dQ=,keyid=masterKey0,iv=WWHpGuOHkwXqxlLxGUqpcA==,format=base64 \ +-blockdev '{"driver":"rbd","pool":"vms","image":"0d59f238-daef-40d4-adf9-a4fa24c35231_disk.config","server":[{"host":"158.69.70.115","port":"6789"}],"user":"cinder","auth-client-required":["cephx","none"],"key-secret":"libvirt-1-storage-secret0","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":true,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"}' \ +-device ide-cd,bus=ide.0,unit=0,drive=libvirt-1-format,id=ide0-0-0,write-cache=on \ +-netdev tap,fd=41,id=hostnet0 \ +-device virtio-net-pci,host_mtu=1400,netdev=hostnet0,id=net0,mac=fa:16:3e:4d:bb:0b,bus=pci.0,addr=0x3 \ +-add-fd set=2,fd=43 \ +-chardev pty,id=charserial0,logfile=/dev/fdset/2,logappend=on \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-vnc 0.0.0.0:3 \ +-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ +-object rng-random,id=objrng0,filename=/dev/urandom \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/1 (label charserial0) + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/testr_results.html + +tempest.api.compute.servers.test_server_rescue_negative.ServerRescueNegativeTestJSON.test_rescued_vm_detach_volume + +2020-09-07 19:30:13,764 100285 INFO [tempest.lib.common.rest_client] Request (ServerRescueNegativeTestJSON:_run_cleanups): 202 DELETE https://158.69.70.115/compute/v2.1/servers/0d59f238-daef-40d4-adf9-a4fa24c35231/os-volume_attachments/04dd79b2-3c05-4492-b1d7-7969d24df768 1.261s +2020-09-07 19:30:13,764 100285 DEBUG [tempest.lib.common.rest_client] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': '<omitted>'} + Body: None + Response - Headers: {'date': 'Mon, 07 Sep 2020 19:30:12 GMT', 'server': 'Apache/2.4.41 (Ubuntu)', 'content-length': '0', 'content-type': 'application/json', 'openstack-api-version': 'compute 2.1', 'x-openstack-nova-api-version': '2.1', 'vary': 'OpenStack-API-Version,X-OpenStack-Nova-API-Version', 'x-openstack-request-id': 'req-502a0106-3eb9-4d42-9dd4-c43ba89187b6', 'x-compute-request-id': 'req-502a0106-3eb9-4d42-9dd4-c43ba89187b6', 'connection': 'close', 'status': '202', 'content-location': 'https://158.69.70.115/compute/v2.1/servers/0d59f238-daef-40d4-adf9-a4fa24c35231/os-volume_attachments/04dd79b2-3c05-4492-b1d7-7969d24df768'} + Body: b'' + +# First attempt to detach the device by n-cpu + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/screen-n-cpu.txt (gzipped) + +29957 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [None req-502a0106-3eb9-4d42-9dd4-c43ba89187b6 tempest-ServerRescueNegativeTestJSON-73411582 tempest-ServerRescueNegativeTestJSON-73411582] detach device xml: <disk type="network" de +29958 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +29959 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +29960 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +29961 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +29962 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +29963 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +29964 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +29965 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> +29966 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: {{(pid=92697) detach_device /opt/stack/nova/nova/virt/libvirt/guest.py:510}} + +# DEVICE_DELETED only raised for /machine/peripheral/virtio-disk1/virtio-backend + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/libvirt/libvirtd_log.txt (gzipped) + +329344 2020-09-07 19:30:14.165+0000: 65559: debug : qemuDomainObjEnterMonitorInternal:9869 : Entering monitor (mon=0x7f769405e470 vm=0x7f768c0df0b0 name=instance-0000003a) +329345 2020-09-07 19:30:14.165+0000: 65559: debug : qemuMonitorDelDevice:2848 : devalias=virtio-disk1 +329346 2020-09-07 19:30:14.165+0000: 65559: debug : qemuMonitorDelDevice:2850 : mon:0x7f769405e470 vm:0x7f768c0df0b0 fd:39 +329347 2020-09-07 19:30:14.165+0000: 65559: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f769405e470 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-367"}^M +329348 fd=-1 +329349 2020-09-07 19:30:14.165+0000: 65555: info : qemuMonitorIOWrite:450 : QEMU_MONITOR_IO_WRITE: mon=0x7f769405e470 buf={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-367"}^M +329350 len=79 ret=79 errno=0 +329351 2020-09-07 19:30:14.168+0000: 65555: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"return": {}, "id": "libvirt-367"}] +329352 2020-09-07 19:30:14.168+0000: 65555: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f769405e470 reply={"return": {}, "id": "libvirt-367"} +329353 2020-09-07 19:30:14.168+0000: 65559: debug : qemuDomainObjExitMonitorInternal:9892 : Exited monitor (mon=0x7f769405e470 vm=0x7f768c0df0b0 name=instance-0000003a) +329354 2020-09-07 19:30:14.201+0000: 65555: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1599507014, "microseconds": 201037}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +329355 2020-09-07 19:30:14.208+0000: 65555: info : qemuMonitorJSONIOProcessLine:234 : QEMU_MONITOR_RECV_EVENT: mon=0x7f769405e470 event={"timestamp": {"seconds": 1599507014, "microseconds": 201037}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}} +329356 2020-09-07 19:30:14.208+0000: 65555: debug : qemuMonitorJSONIOProcessEvent:181 : mon=0x7f769405e470 obj=0x55dd95d0cba0 +329357 2020-09-07 19:30:14.208+0000: 65555: debug : qemuMonitorEmitEvent:1198 : mon=0x7f769405e470 event=DEVICE_DELETED +329358 2020-09-07 19:30:14.208+0000: 65555: debug : qemuProcessHandleEvent:549 : vm=0x7f768c0df0b0 +329359 2020-09-07 19:30:14.208+0000: 65555: debug : virObjectEventNew:631 : obj=0x55dd95d3bf60 +329360 2020-09-07 19:30:14.208+0000: 65555: debug : qemuMonitorJSONIOProcessEvent:205 : handle DEVICE_DELETED handler=0x7f7691732840 data=0x55dd95eae3c0 +329361 2020-09-07 19:30:14.208+0000: 65555: debug : qemuMonitorJSONHandleDeviceDeleted:1287 : missing device in device deleted event + +# Second attempt to detach the device by n-cpu + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/screen-n-cpu.txt (gzipped) + +30046 Sep 07 19:30:19.192548 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG oslo.service.loopingcall [None req-502a0106-3eb9-4d42-9dd4-c43ba89187b6 tempest-ServerRescueNegativeTestJSON-73411582 tempest-ServerRescueNegativeTestJSON-73411582] Waiting for function nova.virt.libvirt.gu +30047 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30048 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30049 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30050 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30051 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30052 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30053 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30054 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30055 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> +30056 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: {{(pid=92697) detach_device /opt/stack/nova/nova/virt/libvirt/guest.py:510}} + +# DeviceNotFound raised by QEMU + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/libvirt/libvirtd_log.txt (gzipped) + +332479 2020-09-07 19:30:19.196+0000: 65560: debug : qemuDomainObjBeginJobInternal:9416 : Starting job: job=modify agentJob=none asyncJob=none (vm=0x7f768c0df0b0 name=instance-0000003a, current job=none agentJob=none async=none) +332480 2020-09-07 19:30:19.196+0000: 65560: debug : qemuDomainObjBeginJobInternal:9470 : Started job: modify (async=none vm=0x7f768c0df0b0 name=instance-0000003a) +332481 2020-09-07 19:30:19.196+0000: 65560: debug : qemuDomainObjEnterMonitorInternal:9869 : Entering monitor (mon=0x7f769405e470 vm=0x7f768c0df0b0 name=instance-0000003a) +332482 2020-09-07 19:30:19.196+0000: 65560: debug : qemuMonitorDelDevice:2848 : devalias=virtio-disk1 +332483 2020-09-07 19:30:19.196+0000: 65560: debug : qemuMonitorDelDevice:2850 : mon:0x7f769405e470 vm:0x7f768c0df0b0 fd:39 +332484 2020-09-07 19:30:19.196+0000: 65560: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f769405e470 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-369"}^M +332485 fd=-1 +332486 2020-09-07 19:30:19.196+0000: 65555: info : qemuMonitorIOWrite:450 : QEMU_MONITOR_IO_WRITE: mon=0x7f769405e470 buf={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-369"}^M +332487 len=79 ret=79 errno=0 +332488 2020-09-07 19:30:19.197+0000: 65555: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"id": "libvirt-369", "error": {"class": "DeviceNotFound", "desc": "Device 'virtio-disk1' not found"}}] +332489 2020-09-07 19:30:19.197+0000: 65555: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f769405e470 reply={"id": "libvirt-369", "error": {"class": "DeviceNotFound", "desc": "Device 'virtio-disk1' not found"}} +332490 2020-09-07 19:30:19.197+0000: 65560: debug : qemuDomainObjExitMonitorInternal:9892 : Exited monitor (mon=0x7f769405e470 vm=0x7f768c0df0b0 name=instance-0000003a) +332491 2020-09-07 19:30:19.197+0000: 65560: debug : qemuDomainDeleteDevice:128 : Detaching of device virtio-disk1 failed and no event arrived + +# n-cpu continues to retry the detach + +30245 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30246 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30247 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30248 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30249 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30250 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30251 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30252 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30253 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30276 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30277 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30278 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30279 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30280 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30281 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30282 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30283 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30284 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30356 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30357 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30358 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30359 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30360 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30361 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30362 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30363 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30364 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30381 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30382 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30383 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30384 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30385 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30386 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30387 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30388 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30389 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30478 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30479 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30480 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30481 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30482 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30483 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30484 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30485 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30486 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30796 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30797 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30798 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30799 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30800 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30801 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30802 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30803 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30804 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +31050 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +31051 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +31052 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +31053 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +31054 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +31055 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +31056 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +31057 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +31058 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +# n-cpu eventually gives up trying to detach the device + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/screen-n-cpu.txt (gzipped) + +31102 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall [-] Dynamic interval looping call 'oslo_service.loopingcall.RetryDecorator.__call__.<locals>._func' failed: nova.exception.DeviceDetachFailed: Device detach failed for vdb: Unable t +31103 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall Traceback (most recent call last): +31104 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py", line 150, in _run_loop +31105 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall result = func(*self.args, **self.kw) +31106 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py", line 428, in _func +31107 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall return self._sleep_time +31108 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ +31109 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall self.force_reraise() +31110 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise +31111 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall six.reraise(self.type_, self.value, self.tb) +31112 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/six.py", line 703, in reraise +31113 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall raise value +31114 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py", line 407, in _func +31115 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall result = f(*args, **kwargs) +31116 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 489, in _do_wait_and_retry_detach +31117 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall raise exception.DeviceDetachFailed( +31118 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall nova.exception.DeviceDetachFailed: Device detach failed for vdb: Unable to detach the device from the live config. +31119 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1898011 b/results/classifier/gemma3:12b/hypervisor/1898011 new file mode 100644 index 00000000..352a9dc4 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1898011 @@ -0,0 +1,31 @@ + +mmap MAP_NORESERVE of 2^42 bytes consumes 16Gb of actual RAM + +Run this program: + +#include <sys/mman.h> +#include <stdio.h> +int main() { + for (int i = 30; i <= 44; i++) { + fprintf(stderr, "trying 2**%d\n", i); + mmap((void*)0x600000000000,1ULL << i, + PROT_NONE, + MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0); + } +} + +(tried qemu-x86_64 and qemu-aarch64, 4.2.1 and trunk/5.1.50) + +On each iteration qemu will consume 2x more physical RAM, +e.g. when mapping 2^42 it will have RSS of 16Gb. + +On normal linux it works w/o consuming much RAM, due to MAP_NORESERVE. + +Also: qemu -strace prints 0 instead of the correct size starting from size=2^32 +and prints -2147483648 for size=2^31. + +mmap(0x0000600000000000,1073741824,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,-2147483648,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,0,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1899 b/results/classifier/gemma3:12b/hypervisor/1899 new file mode 100644 index 00000000..fe620c96 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1899 @@ -0,0 +1,42 @@ + +AArch64: Wrong SCR_EL3 after turning on secondary cores via PSCI +Description of problem: +The system fails to boot when using "direct kernel boot" with EL3 enabled. After the guest OS enables secondary cores via PSCI, those have an incorrectly set up `SCR_EL3`. When the OS then executes an intruction which traps into (QEMU provided fake) EL3, the core ends up in an endless loop of "Undefined Instruction" exceptions. + +This is nicely visible with `-serial stdio -append "earlycon=pl011,0x9000000 console=/dev/ttyAMA0" -d int`: + +```plaintext +[ 0.173173][ T1] smp: Bringing up secondary CPUs ... +(...) +Taking exception 11 [Hypervisor Call] on CPU 0 +...from EL1 to EL2 +...with ESR 0x16/0x5a000000 +...handled as PSCI call +Taking exception 5 [IRQ] on CPU 0 +...from EL1 to EL1 +...with ESR 0x16/0x5a000000 +...with ELR 0xffffa9ff8b593438 +...to EL1 PC 0xffffa9ff8aa11280 PSTATE 0x3c5 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0xffffa9ff8b593438 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0x41f7832c +Taking exception 1 [Undefined Instruction] on CPU 1 +...from EL1 to EL3 +...with ESR 0x18/0x62300882 +...with ELR 0xffffa9ff8aa3d0d8 +...to EL3 PC 0x400 PSTATE 0x3cd +Taking exception 1 [Undefined Instruction] on CPU 1 +...from EL3 to EL3 +...with ESR 0x0/0x2000000 +...with ELR 0x400 +...to EL3 PC 0x200 PSTATE 0x3cd +(repeats forever, CPU 1 is stuck) +``` +Steps to reproduce: +1. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 1 -kernel linux` works +2. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 2 -kernel linux` does not +Additional information: +The setup for `SCR_EL3` is done by `do_cpu_reset` in hw/arm/boot.c, but this is only called on full system reset. The PSCI call ends up in `arm_set_cpu_on_async_work` (target/arm/arm-powerctl.c) which calls `cpu_reset`. This clears `SCR_EL3` to the architectural reset value, not the one needed for direct kernel boot. + +`arm_set_cpu_on_async_work` has code for `SCR_HCE`, but none of the other flags handled by `do_cpu_reset`. It would probably work after copying all of `do_cpu_reset` into `arm_set_cpu_on_async_work`, but that seems wrong. I prepared a patch which makes `do_cpu_reset` public such that `arm_set_cpu_on_async_work` can call it (works here), but I'm not sure whether that's the right way. + +CC @pm215 diff --git a/results/classifier/gemma3:12b/hypervisor/1902365 b/results/classifier/gemma3:12b/hypervisor/1902365 new file mode 100644 index 00000000..3a663a30 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1902365 @@ -0,0 +1,391 @@ + +3x 100% host CPU core usage while virtual machine is in idle + +My Fedora 33 machine "top" command shows qemu-system-x86_64 process using ~300% CPU, that means 3x CPU cores at 100%. Since the virtual machine (named CentOS 8) is almost in idle (top command inside the VM shows ~0% CPU usage), there must be something wrong. I attach qemu process GDB backtrace, and virtual machine libvirt XML + +Host details: +libvirt-6.6.0-2.fc33.x86_64 +qemu-system-x86-5.1.0-5.fc33.x86_64 +virt-manager-3.1.0-1.fc33.noarch +kernel 5.8.16-300.fc33.x86_64 +CPU: AMD Ryzen 5 3600 + +# gdb qemu-system-x86_64 405756 +GNU gdb (GDB) Fedora 9.2-7.fc33 +Copyright (C) 2020 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-redhat-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from qemu-system-x86_64... +Reading symbols from .gnu_debugdata for /usr/bin/qemu-system-x86_64... +(No debugging symbols found in .gnu_debugdata for /usr/bin/qemu-system-x86_64) +Attaching to program: /usr/bin/qemu-system-x86_64, process 405756 +[New LWP 405788] +[New LWP 405798] +[New LWP 405799] +[New LWP 405800] +[New LWP 405801] +[New LWP 405802] +[New LWP 405804] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +0x00007f549d0bdb0e in ppoll () from target:/lib64/libc.so.6 +(gdb) set height 0 +(gdb) set print elements 0 +(gdb) set print frame-arguments all +(gdb) thread apply all backtrace + +Thread 8 (Thread 0x7f53837ff640 (LWP 405804)): +#0 0x00007f549d0bda0f in poll () from target:/lib64/libc.so.6 +#1 0x00007f549e4c2d1e in g_main_context_iterate.constprop () from target:/lib64/libglib-2.0.so.0 +#2 0x00007f549e4716ab in g_main_loop_run () from target:/lib64/libglib-2.0.so.0 +#3 0x00007f549dcfcc66 in red_worker_main.lto_priv () from target:/lib64/libspice-server.so.1 +#4 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#5 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 7 (Thread 0x7f5390dfd640 (LWP 405802)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 6 (Thread 0x7f53915fe640 (LWP 405801)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 5 (Thread 0x7f5391dff640 (LWP 405800)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 4 (Thread 0x7f54988b7640 (LWP 405799)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 3 (Thread 0x7f549917b640 (LWP 405798)): +#0 0x00007f549d0bda0f in poll () from target:/lib64/libc.so.6 +#1 0x00007f549e4c2d1e in g_main_context_iterate.constprop () from target:/lib64/libglib-2.0.so.0 +#2 0x00007f549e4716ab in g_main_loop_run () from target:/lib64/libglib-2.0.so.0 +#3 0x000055a6073c4c81 in iothread_run () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 2 (Thread 0x7f549b93a640 (LWP 405788)): +#0 0x00007f549d0c350d in syscall () from target:/lib64/libc.so.6 +#1 0x000055a6076dce9a in qemu_event_wait () +#2 0x000055a6076e56ca in call_rcu_thread () +#3 0x000055a6076dc0ff in qemu_thread_start () +#4 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#5 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 1 (Thread 0x7f549bb10f00 (LWP 405756)): +#0 0x00007f549d0bdb0e in ppoll () from target:/lib64/libc.so.6 +#1 0x000055a6076f4901 in qemu_poll_ns () +#2 0x000055a6076f0485 in main_loop_wait () +#3 0x000055a60735cdd7 in qemu_main_loop () +#4 0x000055a607234a1e in main () +(gdb) + + + + +# virsh dumpxml centos8 +<domain type='kvm' id='1'> + <name>centos8</name> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://centos.org/centos/8"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>4096000</memory> + <currentMemory unit='KiB'>4096000</currentMemory> + <vcpu placement='static'>4</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>EPYC-IBPB</model> + <vendor>AMD</vendor> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='clwb'/> + <feature policy='require' name='umip'/> + <feature policy='require' name='rdpid'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='perfctr_core'/> + <feature policy='require' name='clzero'/> + <feature policy='require' name='xsaveerptr'/> + <feature policy='require' name='wbnoinvd'/> + <feature policy='require' name='amd-stibp'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='disable' name='npt'/> + <feature policy='disable' name='nrip-save'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + <feature policy='disable' name='monitor'/> + <feature policy='disable' name='svm'/> + <feature policy='require' name='topoext'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8.qcow2' index='6'/> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-1.qcow2' index='5'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='virtio-disk1'/> + <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-2.qcow2' index='4'/> + <backingStore/> + <target dev='vdc' bus='virtio'/> + <alias name='virtio-disk2'/> + <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-3.qcow2' index='3'/> + <backingStore/> + <target dev='vdd' bus='virtio'/> + <alias name='virtio-disk3'/> + <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-4.qcow2' index='2'/> + <backingStore/> + <target dev='vde' bus='virtio'/> + <alias name='virtio-disk4'/> + <address type='pci' domain='0x0000' bus='0x0a' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu'/> + <target dev='sda' bus='sata'/> + <readonly/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='qemu-xhci' ports='15'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='sata' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pcie-root'> + <alias name='pcie.0'/> + </controller> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x10'/> + <alias name='pci.1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x11'/> + <alias name='pci.2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0x12'/> + <alias name='pci.3'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13'/> + <alias name='pci.4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> + </controller> + <controller type='pci' index='5' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='5' port='0x14'/> + <alias name='pci.5'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> + </controller> + <controller type='pci' index='6' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='6' port='0x15'/> + <alias name='pci.6'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> + </controller> + <controller type='pci' index='7' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='7' port='0x16'/> + <alias name='pci.7'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> + </controller> + <controller type='pci' index='8' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='8' port='0x17'/> + <alias name='pci.8'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/> + </controller> + <controller type='pci' index='9' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='9' port='0x18'/> + <alias name='pci.9'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='10' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='10' port='0x19'/> + <alias name='pci.10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d4:02:c2'/> + <source network='default' portid='643b50a3-f347-4c2e-995e-7644a7ad0a96' bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/4'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/4'> + <source path='/dev/pts/4'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-1-centos8/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0' state='connected'/> + <alias name='channel1'/> + <address type='virtio-serial' controller='0' bus='0' port='2'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + <image compression='off'/> + </graphics> + <sound model='ich9'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </sound> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir0'/> + <address type='usb' bus='0' port='2'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir1'/> + <address type='usb' bus='0' port='3'/> + </redirdev> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <alias name='rng0'/> + <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </rng> + </devices> + <seclabel type='dynamic' model='selinux' relabel='yes'> + <label>system_u:system_r:svirt_t:s0:c571,c902</label> + <imagelabel>system_u:object_r:svirt_image_t:s0:c571,c902</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> +</domain> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1902777 b/results/classifier/gemma3:12b/hypervisor/1902777 new file mode 100644 index 00000000..e23cb043 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1902777 @@ -0,0 +1,13 @@ + +qemu with whpx acceleration crashes with vmx=on + +Under Windows 10, qemu crashes when using whpx acceleration and the vmx=on option. The reported error is + qemu-system-x86_64.exe: WHPX: Unexpected VP exit code 4 +Before the error, it reports + Windows Hypervisor Platform accelerator is operational + +The command line is the following: + "C:\Program Files\qemu\qemu-system-x86_64.exe" -accel whpx -cpu qemu64,vmx=on +It crashes with any model of CPU as long as the "vmx=on" option is added. Without this option it runs fine (but no nested virtualization). + +My processor is an Intel i7-10510U, and I am running Windows 10 2004 (build 19041.572). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1904317 b/results/classifier/gemma3:12b/hypervisor/1904317 new file mode 100644 index 00000000..fc7ae78b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1904317 @@ -0,0 +1,23 @@ + +cpu feature selection is not affected to guest 's cpuid with whpx + +On windows with -accel whpx, "-cpu" is ignored without any messages. +Guest recognizes features as same as host's. + +Confirmed on v5.2.0-rc1. + +I suggest qemu may do, + +- Warn with incompatible -cpu options were given. +- Enhance cpuid handling. + +Background: +I was investigated mmio and block copy issue in Linux kernel. +I met a problem that Linux went ill for touching mmio with whpx. (not with tcg) +I suspect erms(enhanced rep movs) might trigger. +I tried to mask erms on qemu with -feature,erms, but it was ineffective. + +At last, I disabled erms manually, to tweak whpx-all.c to mask erms in cpuid. + +FYI, qemu with whpx from/to mmio, "rep movsb" does byte access regardless of erms. +Linux kernel tends to choose not "rep movsq" but "rep movsb" with erms. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1906516 b/results/classifier/gemma3:12b/hypervisor/1906516 new file mode 100644 index 00000000..676fd517 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1906516 @@ -0,0 +1,92 @@ + +[RISCV] sfence.vma need to end the translation block + +QEMU emulator version 5.0.0 + +sfence.vma will flush the tlb, so after this instruction, the translation block should be end. The following code will only work in single step mode: +``` +relocate: + li a0, OFFSET + + la t0, 1f + add t0, t0, a0 + csrw stvec, t0 + + la t0, early_pgtbl + srl t0, t0, PAGE_SHIFT + li t1, SATP_SV39 + or t0, t1, t0 + + csrw satp, t0 +1: + sfence.vma + la t0, trap_s + csrw stvec, t0 + ret +``` + +In this code, I want to relocate pc to virtual address with the OFFSET prefix, before writing to satp, pc run at physic address, stvec has been set a label 1 with a virtual prefix and virtual address has been mapping in early_pgtbl, after writing satp, there will throw a page fault, and pc will set to virtual address of label 1. + +The problem is that, in this situation, the translation block will not end after sfence.vma, and stvec will be set to trap_s, + +``` +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000dc: 00a080b3 add ra,ra,a0 +0x00000000800000e0: 00007297 auipc t0,28672 # 0x800070e0 +0x00000000800000e4: f2028293 addi t0,t0,-224 +0x00000000800000e8: 00c2d293 srli t0,t0,12 +0x00000000800000ec: fff0031b addiw t1,zero,-1 +0x00000000800000f0: 03f31313 slli t1,t1,63 +0x00000000800000f4: 005362b3 or t0,t1,t0 +0x00000000800000f8: 18029073 csrrw zero,satp,t0 + +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000fc: 12000073 sfence.vma zero,zero +0x0000000080000100: 00000297 auipc t0,0 # 0x80000100 +0x0000000080000104: 1c828293 addi t0,t0,456 +0x0000000080000108: 10529073 csrrw zero,stvec,t0 + +riscv_raise_exception: 12 +riscv_raise_exception: 12 +riscv_raise_exception: 12 +riscv_raise_exception: 12 +... +``` + +So, the program will crash, and the program will work in single step mode: +``` +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000f8: 18029073 csrrw zero,satp,t0 + +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000fc: 12000073 sfence.vma zero,zero + +riscv_raise_exception: 12 +---------------- +IN: +Priv: 1; Virt: 0 +0xffffffff800000fc: 12000073 sfence.vma zero,zero + +---------------- +IN: +Priv: 1; Virt: 0 +0xffffffff80000100: 00000297 auipc t0,0 # 0xffffffff80000100 + +``` +The pc will set to label 1, instead of trap_s. + +I try to patch the code in fence.i in trans_rvi.inc.c to sfence.vma: +``` + tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn); + exit_tb(ctx); + ctx->base.is_jmp = DISAS_NORETURN; +``` +This codes can help to end the tranlate block, since I'm not a qemu guy, I'm not sure if this is a corret method. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1908489 b/results/classifier/gemma3:12b/hypervisor/1908489 new file mode 100644 index 00000000..71da3147 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1908489 @@ -0,0 +1,17 @@ + +qemu 4.2 bootloops with -cpu host and nested hypervisor + +I've noticed that after upgrading from Ubuntu 18.04 to 20.04 that nested virtualization isn't working anymore. + +I have a simple repro where I create a Windows 10 2004 guest and enable Hyper-V in it. This worked fine in 18.04 and specifically qemu <4.2 (I specifically tested Qemu 2.11-4.1 which work fine). + +The -cpu arg I'm passing is simply: + -cpu host,l3-cache=on,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + +Using that Windows won't boot because the nested hypervisor (Hyper-V) is unable to be initialize and so it just boot loops. Using the exact same qemu command works fine with 4.1 and lower. + +Switching to a named CPU model like Skylake-Client-noTSX-IBRS instead of host lets the VM boot but causes some weird behaviour later trying to use nested VMs. + +If I had to guess I think it would probably be related to this change https://github.com/qemu/qemu/commit/20a78b02d31534ae478779c2f2816c273601e869 which would line up with 4.2 being the first bad version but unsure. + +For now I just have to keep an older build of QEMU to work around this. Let me know if there's anything else needed. I can also try out any patches. I already have at least a dozen copies of qemu lying around now. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1909921 b/results/classifier/gemma3:12b/hypervisor/1909921 new file mode 100644 index 00000000..fb0a1097 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1909921 @@ -0,0 +1,23 @@ + + Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e + +Hello, + +I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM Edition). +I created a CentOS 7 VM on it and I'm using a Docker container which is running qemu inside it. + +This container is a Debian Bullseye OS and I'm using qemu-i386 to start my application inside it. +The error given by qemu is the following : + +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff9d5f9b0e +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff82f29b0e + +(The pc= value is always different, I guess it is randomly generated). + +My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1) + +Could you please help me? Why am I facing this error? + +Feel free to ask any questions regarding this matter in order to find a solution to it! + +Regards \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1911351 b/results/classifier/gemma3:12b/hypervisor/1911351 new file mode 100644 index 00000000..18953dda --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1911351 @@ -0,0 +1,42 @@ + +x86-64 MTTCG Does not update page table entries atomically + +It seems like the qemu tcg code for x86-64 doesn't write the access and dirty flags of the page table entries atomically. Instead, they first read the entry, see if they need to set the page table entry, and then overwrite the entry. So if you have two threads running at the same time, one accessing the virtual address over and over again, and the other modifying the page table entry, it is possible that after the second thread modifies the page table entry, qemu overwrites the value with the old page table entry value, with the access/dirty flags set. + +Here's a unit test that reproduces this behavior: + +https://github.com/mvanotti/kvm-unit-tests/commit/09f9722807271226a714b04f25174776454b19cd + +You can run it with: + +``` +/usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \ +-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \ +-vnc none -serial stdio -device pci-testdev \ +-smp 4 -machine q35 --accel tcg,thread=multi \ +-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf +``` + +Expected output (failure): + +``` +kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf +enabling apic +enabling apic +enabling apic +enabling apic +paging enabled +cr0 = 80010011 +cr3 = 627000 +cr4 = 20 +found 4 cpus +PASS: Need more than 1 CPU +Detected overwritten PTE: + want: 0x000000000062e007 + got: 0x000000000062d027 +FAIL: PTE not overwritten +PASS: All Reads were zero +SUMMARY: 3 tests, 1 unexpected failures +``` + +This bug has allows user-to-root privilege escalation inside the guest VM: if the user is able overwrite an entry that belongs to a second-to-last level page table, and is able to allocate the referenced page, then the user would be in control of a last-level page table, being able to map any memory they want. This is not uncommon in situations where memory is being decomitted. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1912 b/results/classifier/gemma3:12b/hypervisor/1912 new file mode 100644 index 00000000..f8283b97 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1912 @@ -0,0 +1,2 @@ + +linux-user: (recursive) segfault when built with -static -disable-pie diff --git a/results/classifier/gemma3:12b/hypervisor/1912170 b/results/classifier/gemma3:12b/hypervisor/1912170 new file mode 100644 index 00000000..ab1c097c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1912170 @@ -0,0 +1,49 @@ + +NUMA nodes created with memory-backend-ram shows size different than requested + +I created system with 7 NUMA nodes where nodes 0-3 should have 268435456 bytes size and nodes 4-6 exactly 1610612736 bytes size, but when I run "numactl -H" I got different (smaller) sizes. +It is essential for me to be able to emulate a system with nodes of exact size - is it possible? + +QEMU version: + +QEMU emulator version 5.1.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +QEMU command: + +qemu-system-x86_64 -hda qemu-image/ubuntu-1804.img -enable-kvm -cpu Cascadelake-Server -vnc :5 -netdev user,id=net0,hostfwd=tcp::10022-:22 -device virtio-net,netdev=net0 -boot c -m 5632.0M -object memory-backend-ram,id=ram-node0,size=268435456 -numa node,nodeid=0,cpus=0-3,memdev=ram-node0 -object memory-backend-ram,id=ram-node1,size=268435456 -numa node,nodeid=1,cpus=4-7,memdev=ram-node1 -object memory-backend-ram,id=ram-node2,size=268435456 -numa node,nodeid=2,cpus=8-11,memdev=ram-node2 -object memory-backend-ram,id=ram-node3,size=268435456 -numa node,nodeid=3,cpus=12-15,memdev=ram-node3 -object memory-backend-ram,id=ram-node4,size=1610612736 -numa node,nodeid=4,memdev=ram-node4 -object memory-backend-ram,id=ram-node5,size=1610612736 -numa node,nodeid=5,memdev=ram-node5 -object memory-backend-ram,id=ram-node6,size=1610612736 -numa node,nodeid=6,memdev=ram-node6 -numa dist,src=0,dst=0,val=10 -numa dist,src=0,dst=1,val=21 -numa dist,src=0,dst=2,val=31 -numa dist,src=0,dst=3,val=21 -numa dist,src=0,dst=4,val=17 -numa dist,src=0,dst=5,val=38 -numa dist,src=0,dst=6,val=28 -numa dist,src=1,dst=0,val=21 -numa dist,src=1,dst=1,val=10 -numa dist,src=1,dst=2,val=21 -numa dist,src=1,dst=3,val=31 -numa dist,src=1,dst=4,val=28 -numa dist,src=1,dst=5,val=17 -numa dist,src=1,dst=6,val=38 -numa dist,src=2,dst=0,val=31 -numa dist,src=2,dst=1,val=21 -numa dist,src=2,dst=2,val=10 -numa dist,src=2,dst=3,val=21 -numa dist,src=2,dst=4,val=28 -numa dist,src=2,dst=5,val=28 -numa dist,src=2,dst=6,val=28 -numa dist,src=3,dst=0,val=21 -numa dist,src=3,dst=1,val=31 -numa dist,src=3,dst=2,val=21 -numa dist,src=3,dst=3,val=10 -numa dist,src=3,dst=4,val=28 -numa dist,src=3,dst=5,val=28 -numa dist,src=3,dst=6,val=17 -numa dist,src=4,dst=0,val=17 -numa dist,src=4,dst=1,val=28 -numa dist,src=4,dst=2,val=28 -numa dist,src=4,dst=3,val=28 -numa dist,src=4,dst=4,val=10 -numa dist,src=4,dst=5,val=28 -numa dist,src=4,dst=6,val=28 -numa dist,src=5,dst=0,val=38 -numa dist,src=5,dst=1,val=17 -numa dist,src=5,dst=2,val=28 -numa dist,src=5,dst=3,val=28 -numa dist,src=5,dst=4,val=28 -numa dist,src=5,dst=5,val=10 -numa dist,src=5,dst=6,val=28 -numa dist,src=6,dst=0,val=38 -numa dist,src=6,dst=1,val=28 -numa dist,src=6,dst=2,val=28 -numa dist,src=6,dst=3,val=17 -numa dist,src=6,dst=4,val=28 -numa dist,src=6,dst=5,val=28 -numa dist,src=6,dst=6,val=10 -smp 16,sockets=4,dies=1,cores=4,threads=1 -fsdev local,security_model=passthrough,id=fsdev0,path=/home/mysuser/share -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=share_host -daemonize + +output from numactl -H: + +$ numactl -H +available: 7 nodes (0-6) +node 0 cpus: 0 1 2 3 +node 0 size: 250 MB +node 0 free: 191 MB +node 1 cpus: 4 5 6 7 +node 1 size: 251 MB +node 1 free: 199 MB +node 2 cpus: 8 9 10 11 +node 2 size: 251 MB +node 2 free: 218 MB +node 3 cpus: 12 13 14 15 +node 3 size: 251 MB +node 3 free: 118 MB +node 4 cpus: +node 4 size: 1511 MB +node 4 free: 1507 MB +node 5 cpus: +node 5 size: 1447 MB +node 5 free: 1443 MB +node 6 cpus: +node 6 size: 1489 MB +node 6 free: 1484 MB +node distances: +node 0 1 2 3 4 5 6 + 0: 10 21 31 21 17 38 28 + 1: 21 10 21 31 28 17 38 + 2: 31 21 10 21 28 28 28 + 3: 21 31 21 10 28 28 17 + 4: 17 28 28 28 10 28 28 + 5: 38 17 28 28 28 10 28 + 6: 38 28 28 17 28 28 10 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1913916 b/results/classifier/gemma3:12b/hypervisor/1913916 new file mode 100644 index 00000000..627667c3 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1913916 @@ -0,0 +1,69 @@ + +aarch64-virt: heap-buffer-overflow in address_space_lookup_region + +Reproducer: +cat << EOF | ./qemu-system-aarch64 \ +-machine virt,accel=qtest -qtest stdio +writel 0x8000f00 0xff4affb0 +writel 0x8000f00 0xf2f8017f +writeq 0x801000e 0x5a5a5a6c8ff7004b +writeq 0x8010010 0x5a5a5a5a73ba2f00 +writel 0x8000000 0x3bf5a03 +writel 0x8000000 0x3bf5a03 +writeq 0x8010000 0x10ffff03fbffffff +writel 0x8000f1f 0x5a55fc00 +readl 0x8011f00 +readl 0x80000d3 +readl 0x80000d3 +clock_step +writeq 0x4010008004 0x4604fffdffc54c01 +writeq 0x4010008002 0xf7478b3f5aff5a55 +writel 0x8000f00 0x2d6954 +writel 0x800005a 0x2706fcf +readq 0x800002c +readw 0x9000004 +readq 0x800002c +writeq 0x801000e 0x5555017f00017f00 +writew 0x8010000 0x55 +writew 0x8010000 0x465a +writew 0x8010000 0x55 +writew 0x8010000 0xaf00 +writeq 0x8010015 0x3b5a5a5555460000 +writeq 0x8010015 0xd546002b2b000000 +writeq 0x8010015 0xc44ea5aaaab9ffff +readq 0x8000a5a +EOF + +Stacktrace: +==638893==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x629000022b84 at pc 0x55915c484d92 bp 0x7ffcde114a00 sp 0x7ffcde1149f8 +READ of size 2 at 0x629000022b84 thread T0 + #0 0x55915c484d91 in address_space_lookup_region /home/alxndr/Development/qemu/build/../softmmu/physmem.c:345:36 + #1 0x55915c484d91 in address_space_translate_internal /home/alxndr/Development/qemu/build/../softmmu/physmem.c:359:15 + #2 0x55915c481d90 in flatview_do_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:497:15 + #3 0x55915c48214e in flatview_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:563:15 + #4 0x55915c107ff9 in address_space_read /home/alxndr/Development/qemu/include/exec/memory.h:2477:18 + #5 0x55915c107ff9 in qtest_process_command /home/alxndr/Development/qemu/build/../softmmu/qtest.c:572:13 + #6 0x55915c102b97 in qtest_process_inbuf /home/alxndr/Development/qemu/build/../softmmu/qtest.c:797:9 + #7 0x55915c953286 in fd_chr_read /home/alxndr/Development/qemu/build/../chardev/char-fd.c:68:9 + #8 0x7f02be25daae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) + #9 0x55915cfae363 in glib_pollfds_poll /home/alxndr/Development/qemu/build/../util/main-loop.c:232:9 + #10 0x55915cfae363 in os_host_main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:255:5 + #11 0x55915cfae363 in main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:531:11 + #12 0x55915c069599 in qemu_main_loop /home/alxndr/Development/qemu/build/../softmmu/runstate.c:721:9 + #13 0x55915a2f61fd in main /home/alxndr/Development/qemu/build/../softmmu/main.c:50:5 + #14 0x7f02bdd02cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #15 0x55915a249bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +0x629000022b84 is located 660 bytes to the right of 18160-byte region [0x62900001e200,0x6290000228f0) +allocated by thread T0 here: + #0 0x55915a2c3c3d in malloc (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x33cac3d) + #1 0x7f02be263a88 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57a88) + #2 0x55915c932cbd in qdev_new /home/alxndr/Development/qemu/build/../hw/core/qdev.c:153:19 + #3 0x55915b559360 in create_gic /home/alxndr/Development/qemu/build/../hw/arm/virt.c:631:16 + #4 0x55915b5449d2 in machvirt_init /home/alxndr/Development/qemu/build/../hw/arm/virt.c:1966:5 + #5 0x55915a62bac0 in machine_run_board_init /home/alxndr/Development/qemu/build/../hw/core/machine.c:1169:5 + #6 0x55915c02b8d8 in qemu_init_board /home/alxndr/Development/qemu/build/../softmmu/vl.c:2455:5 + #7 0x55915c02b8d8 in qmp_x_exit_preconfig /home/alxndr/Development/qemu/build/../softmmu/vl.c:2526:5 + #8 0x55915c035d91 in qemu_init /home/alxndr/Development/qemu/build/../softmmu/vl.c:3533:9 + #9 0x55915a2f61f8 in main /home/alxndr/Development/qemu/build/../softmmu/main.c:49:5 + #10 0x7f02bdd02cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1914353 b/results/classifier/gemma3:12b/hypervisor/1914353 new file mode 100644 index 00000000..1446114c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1914353 @@ -0,0 +1,51 @@ + +QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID + +Via [qemu-security] list + ++-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+ +| On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote: +| > Per the ARM Generic Interrupt Controller Architecture specification +| > (document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit, +| > not 10: +| > +| > - Table 4-21 GICD_SGIR bit assignments +| > +| > The Interrupt ID of the SGI to forward to the specified CPU +| > interfaces. The value of this field is the Interrupt ID, in +| > the range 0-15, for example a value of 0b0011 specifies +| > Interrupt ID 3. +| > +... +| > Correct the irq mask to fix an undefined behavior (which eventually +| > lead to a heap-buffer-overflow, see [Buglink]): +| > +| > $ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M virt,accel=qtest -qtest stdio +| > [I 1612088147.116987] OPENED +| > [R +0.278293] writel 0x8000f00 0xff4affb0 +| > ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for type 'uint8_t [16][8]' +| > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1498:13 +| > +| > Cc: <email address hidden> +| > Fixes: 9ee6e8bb853 ("ARMv7 support.") +| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916 +| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917 +... + +On 210202 1221, Peter Maydell wrote: +> In both cases the overrun is on the first writel to 0x8000f00, +> but the fuzzer has for some reason not reported that but instead +> blundered on until it happens to trigger some other issue that +> resulted from the memory corruption it induced with the first write. +> +... +> On the CVE: +> +> Since this can affect systems using KVM, this is a security bug for +> us. However, it only affects an uncommon configuration: +> you are only vulnerable if you are using "kernel-irqchip=off" +> (the default is 'on', and turning it off is an odd thing to do). +> +> thanks +> -- PMM +> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1915431 b/results/classifier/gemma3:12b/hypervisor/1915431 new file mode 100644 index 00000000..c7ab3dc3 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1915431 @@ -0,0 +1,12 @@ + +QEMU processes started by Acceptance Tests are left running + +Every now and then, QEMU processes started by the Acceptance Tests (thus by Avocado) will be left running. + +From Avocado's perspective, when everything "goes well" and a test reaches completion, there's no attempt to terminate any processes it indirectly started. Some frameworks and tests built on top of Avocado, for instance Avocado-VT, will keep processes running between various tests. + +When a job (and consequently a test) is manually interrupted, then Avocado tries to terminate the entire process tree. + +It may be possible to improve the situation in which, at the very least, the user is: + * notified of left over processes + * have a configuration option that will attempt to kill all processes at the end of the test execution \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1916343 b/results/classifier/gemma3:12b/hypervisor/1916343 new file mode 100644 index 00000000..b820906e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1916343 @@ -0,0 +1,24 @@ + +-daemonize not working on macOS + +Basically e.g, if I try with below command on macOS: + +qemu-system-x86_64 \ + -m 4G \ + -vga virtio \ + -display default,show-cursor=on \ + -usb \ + -device usb-tablet \ + -machine type=q35,accel=hvf \ + -smp 2 \ + -drive file=ubuntu.qcow2,if=virtio -cpu max \ + -net nic -net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 \ + -daemonize + +With this command, the QEMU processes hang there forever. I guess there is a bug when forking a child and kill the parent? Because when this issue occurs, there are actually 2 QEMU processes running + +``` + 501 14952 14951 0 7:08PM ?? 0:00.00 (qemu-system-x86_) + 501 14953 1 0 7:08PM ?? 0:00.03 qemu-system-x86_64 -m 4G -vga virtio -display default,show-cursor=on -usb -device usb-tablet -machine type=q35,accel=hvf -smp 2 -drive file=ubuntu.qcow2,if=virtio -cpu max -net nic -net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 -daemonize + 501 14951 14626 0 7:08PM ttys000 0:00.03 qemu-system-x86_64 -m 4G -vga virtio -display default,show-cursor=on -usb -device usb-tablet -machine type=q35,accel=hvf -smp 2 -drive file=ubuntu.qcow2,if=virtio -cpu max -net nic -net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 -daemonize +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1917 b/results/classifier/gemma3:12b/hypervisor/1917 new file mode 100644 index 00000000..d2bd3663 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1917 @@ -0,0 +1,52 @@ + +cargo on ppc64 fails: invalid instruction: *EDIT*: on ntpdate as well +Description of problem: +Machine boots, +but when compiling a rust library, the following issue appears: +``` +cargo build --release --manifest-path rust-src/Cargo.toml +cargo[376]: illegal instruction (4) at 12e0933c0 nip 12e0933c0 lr 12dd7c768 code 1 in cargo[12dc10000+956000] +cargo[376]: code: 00000000 00000000 00000000 7c0802a6 f8010010 f821ff11 fba100d8 60000000 +cargo[376]: code: fbc100e0 8862cd50 28030000 418200d4 <104214c4> 38810070 3bc00000 7c4021ce +make: *** [Makefile:133: rust-src/target/release/libbcachefs_rust.a] Illegal instruction (core dumped) +make: *** Waiting for unfinished jobs.... +ar[375]: illegal instruction (4) at 3fff9b2a4dac nip 3fff9b2a4dac lr 3fff9b2a4da4 code 1 in libLLVM-16.so.1[3fff99f10000+792f000] +ar[375]: code: f87d0028 7fa3eb78 b29d0090 f89d0020 4810a8c1 60000000 7f83e378 7fa4eb78 +ar[375]: code: 7fc5f378 49bfd3e1 e8410028 60000000 <104214c4> 38810070 fb610080 eba29fe0 +make: *** [Makefile:129: libbcachefs.a] Illegal instruction (core dumped) +make: *** Deleting file 'libbcachefs.a' +``` +the core dump files of cargo and ar are attached + +~~I have no clue whether this is a rustc or qemu bug, so please let me know if this issue should be forwarded to rust devs~~ +EDIT: as this happens with ntpdate as well, I think it's an emulator issue: + +``` +ntpdig[1179]: illegal instruction (4) at 102382c4 nip 102382c4 lr 102382a8 code 1 in python3.11[10000000+63e000] +ntpdig[1179]: code: 3d22ffdd c8094448 fc1e0000 41c2022c 4bde9b5d e8410028 3d42ffdd 39200000 +ntpdig[1179]: code: c80a4450 91230000 fc1e0000 41c001a4 <ffe0f02c> fc1ff800 41c30280 3d22ffdd +``` +Steps to reproduce: +1. create a debian ppc64 root image using debian sid & debootstrap +2. install rust using rustup +3. compile bcachefs-tools in ppc64 + +2b. Install ntpdate using apt-get ntpdate +3b. run ntpdate +Additional information: +Core dump command: +``` +cat /proc/sys/kernel/core_pattern +|/bin/cp --sparse=always /dev/stdin /host//repos/janpieter/linux/bcachefs/ktest-out/core.%e.PID%p.SIG%s.TIME%t +``` + + +[core.ar.PID374.SIG4.TIME1696070088.xz](/uploads/6a540c4d13351871b1e22153ad87ab99/core.ar.PID374.SIG4.TIME1696070088.xz) AR core dump + +[core.ar.PID375.SIG4.TIME1696070088.xz](/uploads/7c314eba58c2190e3a9fbd88f8eb1242/core.ar.PID375.SIG4.TIME1696070088.xz) AR core dump + +[core.cargo.PID375.SIG4.TIME1696070087.xz](/uploads/0097d457eb2d25e0123874b59405647a/core.cargo.PID375.SIG4.TIME1696070087.xz) cargo core dump + +[core.cargo.PID376.SIG4.TIME1696070087.xz](/uploads/53834fa9608036d6de9dafc3f778f165/core.cargo.PID376.SIG4.TIME1696070087.xz) cargo core dump + +[core.ntpdig.PID1171.SIG4.TIME1696070657.xz](/uploads/8a96d86338d7c6bebe39657a24f570d8/core.ntpdig.PID1171.SIG4.TIME1696070657.xz) ntpdig core dump diff --git a/results/classifier/gemma3:12b/hypervisor/1919253 b/results/classifier/gemma3:12b/hypervisor/1919253 new file mode 100644 index 00000000..fe1977ba --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1919253 @@ -0,0 +1,87 @@ + +QEMU doesn't build reproducibly anymore in 5.2.0 + +It used to be that building QEMU 5.1.0 twice in a row, using Guix, would result in bit-for-bit identical results. + +Starting with 5.2.0, this is no longer true. Here's a summary of which files have non-determinism: + +Here's a summary of the differing files: + +$ diff -r /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0{,-check} +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-aarch64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-aarch64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-aarch64_be and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-aarch64_be differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-alpha and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-alpha differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-arm and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-arm differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-armeb and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-armeb differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-cris and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-cris differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-edid and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-edid differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-ga and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-ga differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-hppa and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-hppa differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-i386 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-i386 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-img and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-img differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-io and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-io differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-keymap and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-keymap differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-m68k and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-m68k differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-microblaze and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-microblaze differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-microblazeel and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-microblazeel differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mips and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mips differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mips64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mips64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mips64el and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mips64el differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mipsel and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mipsel differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mipsn32 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mipsn32 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mipsn32el and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mipsn32el differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-nbd and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-nbd differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-nios2 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-nios2 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-or1k and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-or1k differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-ppc and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-ppc differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-ppc64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-ppc64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-ppc64le and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-ppc64le differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-pr-helper and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-pr-helper differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-riscv32 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-riscv32 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-riscv64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-riscv64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-s390x and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-s390x differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-sh4 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-sh4 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-sh4eb and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-sh4eb differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-sparc and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-sparc differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-sparc32plus and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-sparc32plus differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-sparc64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-sparc64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-storage-daemon and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-storage-daemon differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-aarch64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-aarch64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-alpha and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-alpha differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-arm and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-arm differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-avr and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-avr differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-cris and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-cris differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-hppa and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-hppa differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-i386 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-i386 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-m68k and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-m68k differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-microblaze and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-microblaze differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-microblazeel and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-microblazeel differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-mips and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-mips differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-mips64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-mips64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-mips64el and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-mips64el differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-mipsel and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-mipsel differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-moxie and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-moxie differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-nios2 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-nios2 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-or1k and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-or1k differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-ppc and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-ppc differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-ppc64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-ppc64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-riscv32 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-riscv32 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-riscv64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-riscv64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-rx and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-rx differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-s390x and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-s390x differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-sh4 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-sh4 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-sh4eb and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-sh4eb differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-sparc and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-sparc differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-sparc64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-sparc64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-tricore and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-tricore differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-x86_64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-x86_64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-xtensa and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-xtensa differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-system-xtensaeb and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-system-xtensaeb differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-x86_64 and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-x86_64 differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-xtensa and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-xtensa differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-xtensaeb and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-xtensaeb differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/libexec/qemu-bridge-helper and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/libexec/qemu-bridge-helper differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/libexec/vhost-user-gpu and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/libexec/vhost-user-gpu differ +Binary files /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/libexec/virtiofsd and /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/libexec/virtiofsd differ + +Attached is a sample log of diffoscope for the qemu-aarch64 binary. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1920 b/results/classifier/gemma3:12b/hypervisor/1920 new file mode 100644 index 00000000..1e10b496 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1920 @@ -0,0 +1,12 @@ + +regrssion on 8.1.x: java/maven fails to run on qemu-aarch64 +Description of problem: +Java process crashes when running simple "mvn -version" command inside qemu-aarch64. "java -version" works. +Last known working version: 8.0.3 (qemu-8.0.3-4.fc39) +Failing versions: 8.1.1 (qemu-8.1.1-1.fc39) and 8.1.0 (qemu-8.1.0-1.fc39) +The same image works on native arm64 machine. +Steps to reproduce: +1. podman run --platform linux/arm64 docker.io/library/maven:3.9-eclipse-temurin-20 mvn -version +2. should display few lines of version information and not a NullPointerException +Additional information: +podman version 4.7.0 diff --git a/results/classifier/gemma3:12b/hypervisor/1920934 b/results/classifier/gemma3:12b/hypervisor/1920934 new file mode 100644 index 00000000..3bdfb117 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1920934 @@ -0,0 +1,118 @@ + +Heap-use-after-free in io_writex / cputlb.c results in Linux kernel crashes + +qemu version: git 5ca634afcf83215a9a54ca6e66032325b5ffb5f6; 5.2.0 + +We've encountered that booting the Linux kernel in TCG mode, results in a racy heap-use-after-free. The bug can be detected by ASan [A], but in the majority of runs results in a crashing kernel [B]. + +To reproduce, the following command line was used: + +$> while ./qemu-system-x86_64 -no-reboot -smp 10 -m 2G -kernel arch/x86/boot/bzImage -nographic -append "oops=panic panic_on_warn=1 panic=1 kfence.sample_interval=1 nokaslr"; do sleep 0.5s; done + +The crashes in the kernel [B] appear to receive an interrupt in a code location where the instructions are periodically patched (via the jump_label infrastructure). + +[A]: +================================================================= +==3552508==ERROR: AddressSanitizer: heap-use-after-free on address 0x6190007fef50 at pc 0x55885b0b4d1b bp 0x7f83baffb800 sp 0x7f83baffb7f8 +READ of size 8 at 0x6190007fef50 thread T4 +[ 4.616506][ T1] pci 0000:00:02.0: reg 0x18: [mem 0xfebf0000-0xfebf0fff] +[ 4.670567][ T1] pci 0000:00:02.0: reg 0x30: [mem 0xfebe0000-0xfebeffff pref] +[ 4.691345][ T1] pci 0000:00:03.0: [8086:100e] type 00 class 0x020000 +[ 4.701540][ T1] pci 0000:00:03.0: reg 0x10: [mem 0xfebc0000-0xfebdffff] +[ 4.711076][ T1] pci 0000:00:03.0: reg 0x14: [io 0xc000-0xc03f] +[ 4.746869][ T1] pci 0000:00:03.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref] +[ 4.813612][ T1] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) + #0 0x55885b0b4d1a in io_writex ../accel/tcg/cputlb.c:1408 + #1 0x55885b0d3b9f in store_helper ../accel/tcg/cputlb.c:2444 + #2 0x55885b0d3b9f in helper_le_stl_mmu ../accel/tcg/cputlb.c:2510 +[ 4.820927][ T1] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) + #3 0x7f843cedf8dc (<unknown module>) + +0x6190007fef50 is located 208 bytes inside of 1024-byte region [0x6190007fee80,0x6190007ff280) +freed by thread T11 here: + #0 0x7f8483f431f8 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164 + #1 0x7f8483586de7 in g_realloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57de7) + +previously allocated by thread T11 here: + #0 0x7f8483f431f8 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164 + #1 0x7f8483586de7 in g_realloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57de7) + +Thread T4 created by T0 here: +[ 4.827679][ T1] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) +[ 4.835143][ T1] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) +[ 4.838441][ T1] ACPI: PCI Interrupt Link [LNKS] (IRQs *9) + #0 0x7f8483eee2a2 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:214 + #1 0x55885b7cf0de in qemu_thread_create ../util/qemu-thread-posix.c:558 + +Thread T11 created by T0 here: + #0 0x7f8483eee2a2 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:214 + #1 0x55885b7cf0de in qemu_thread_create ../util/qemu-thread-posix.c:558 + +SUMMARY: AddressSanitizer: heap-use-after-free ../accel/tcg/cputlb.c:1408 in io_writex +Shadow bytes around the buggy address: + 0x0c32800f7d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c32800f7da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c32800f7db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c32800f7dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c32800f7dd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +=>0x0c32800f7de0: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd + 0x0c32800f7df0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800f7e00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800f7e10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800f7e20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800f7e30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==3552508==ABORTING + + +[B]: +[ 6.029269][ C4] int3: 0000 [#1] PREEMPT SMP +[ 6.029269][ C4] CPU: 4 PID: 34 Comm: cpuhp/4 Not tainted 5.12.0-rc4 #2 +[ 6.029269][ C4] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 +[ 6.029269][ C4] RIP: 0010:kmem_cache_alloc_trace+0xdd/0x2f0 +[ 6.029269][ C4] Code: de e8 a7 2e 02 00 85 c0 74 0d 48 89 ef e8 bb 60 00 00 e9 e3 00 00 00 4d 85 f6 0f 84 da 00 00 00 4c 89 6c 24 08 48 8b 2c 24 cc <98> 01 00 00 45 31 ed 4c 89 6c 24 10 4d 85 ed 0f 85 99 00 00 00 49 +[ 6.029269][ C4] RSP: 0018:ffffc90000483cc0 EFLAGS: 00000286 +[ 6.029269][ C4] RAX: 0000000000000000 RBX: 0000000000000dc0 RCX: ffff888003b717c0 +[ 6.029269][ C4] RDX: 0000000000000000 RSI: 0000000000000dc0 RDI: ffff888003842a00 +[ 6.029269][ C4] RBP: 0000000000000110 R08: 0000000000000000 R09: 0000000000000000 +[ 6.029269][ C4] R10: ffffffff81248e22 R11: 00000000fa83b201 R12: 0000000000000dc0 +[ 6.029269][ C4] R13: 0000000000000000 R14: ffff888003842a00 R15: ffffffff8150e1c9 +[ 6.029269][ C4] FS: 0000000000000000(0000) GS:ffff88803ea00000(0000) knlGS:0000000000000000 +[ 6.029269][ C4] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 6.029269][ C4] CR2: 0000000000000000 CR3: 0000000002011000 CR4: 00000000000006e0 +[ 6.029269][ C4] Call Trace: +[ 6.029269][ C4] device_add+0x59/0x7b0 +[ 6.029269][ C4] device_create+0xea/0x130 +[ 6.029269][ C4] ? cpu_report_death+0x40/0x40 +[ 6.029269][ C4] ? cpu_report_death+0x40/0x40 +[ 6.029269][ C4] ? msr_devnode+0x20/0x20 +[ 6.029269][ C4] msr_device_create+0x28/0x40 +[ 6.029269][ C4] cpuhp_invoke_callback+0x140/0x2f0 +[ 6.029269][ C4] ? finish_task_switch+0x8c/0x230 +[ 6.029269][ C4] ? cpu_report_death+0x40/0x40 +[ 6.029269][ C4] cpuhp_thread_fun+0x118/0x1a0 +[ 6.029269][ C4] ? cpu_report_death+0x40/0x40 +[ 6.029269][ C4] smpboot_thread_fn+0x1b9/0x270 +[ 6.029269][ C4] kthread+0x14b/0x160 +[ 6.029269][ C4] ? kthread_unuse_mm+0xf0/0xf0 +[ 6.029269][ C4] ret_from_fork+0x1f/0x30 +[ 6.029269][ C4] ---[ end trace 1336f71544bb94e4 ]--- \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1921082 b/results/classifier/gemma3:12b/hypervisor/1921082 new file mode 100644 index 00000000..dc135037 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1921082 @@ -0,0 +1,17 @@ + +VM crash when process broadcast MCE + +When i do memory SRAR test for VM, I meet the following issue: + +My VM has 16 vCPU, I will inject one UE error to memory which is accessed by VM, Then host MCE is raised and SIGBUS is send to VM, and qemu take control. +Qemu will check the broadcast attribute by following cpu_x86_support_mca_broadcast(); + +Then Qemu may inject MCE to all vCPU, as vCPU is just one process for HOST, we can't guarantee all the vCPUs will enter MCE hander in 1S sync time, and the VM may panic. + +This issue will be easily fixed by expand monarch_timeout configuration, but the exact monarch_timeout can't be easily got, as it will depand on the num of vCPUs and current system schedule status. + +I am wondering why VM need broadcast attribute for MCE, When qeme process MCE event form host, it will always be signaled for one vCPU? If so, why does qemu need boradcast the MCE event to all vCPUs? + +Can weu just deliver LMCE to one specifc vCPU and make this behavior default? + +If anything wrong, Please point out. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1922611 b/results/classifier/gemma3:12b/hypervisor/1922611 new file mode 100644 index 00000000..4a7a9e1c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1922611 @@ -0,0 +1,44 @@ + +Acceptance Tests: migration fails on sparc target + +QEMU fails migration when using a sparc target. + +This cab be verified/reproduced with the `tests/acceptance/migration.py` test. Running it with: + + $ make check-venv + $ ./tests/venv/bin/avocado --show=test run -p qemu_bin=./qemu-system-sparc tests/acceptance/migration.py:Migration.test_migration_with_tcp_localhost + +Right after a QMP `query-migrate` is executed, communication with the monitor is lost: + +>>> {'execute': 'query-migrate'} +<<< {'timestamp': {'seconds': 1617667984, 'microseconds': 330282}, 'event': 'STOP'} +<<< {'return': {'blocked': False, 'status': 'completed', 'setup-time': 0, 'downtime': 1, 'total-time': 15, 'ram': {'total': 135274496, 'postcopy-requests': 0, 'dirty-sync-count': 2, 'multifd-bytes': 0, 'pages-per-second': 0, 'page-size': 4096, 'remaining': 0, 'mbps': 301.2234666666667, 'transferred': 528703, 'duplicate': 33202, 'dirty-pages-rate': 0, 'skipped': 0, 'normal-bytes': 229376, 'normal': 56}}} +>>> {'execute': 'query-migrate'} + +Reproduced traceback from: /var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.7/site-packages/avocado/core/test.py:756 +Traceback (most recent call last): + File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 80, in test_migration_with_tcp_localhost + self.do_migrate(dest_uri) + File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 69, in do_migrate + self.assert_migration(source_vm, dest_vm) + File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 41, in assert_migration + args=(dst_vm,)) + File "/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.7/site-packages/avocado/utils/wait.py", line 34, in wait_for + output = func(*args, **kwargs) + File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 31, in migration_finished + return vm.command('query-migrate')['status'] in ('completed', 'failed') + File "/home/cleber/src/qemu/python/qemu/machine.py", line 572, in command + return self._qmp.command(cmd, **qmp_args) + File "/home/cleber/src/qemu/python/qemu/qmp.py", line 284, in command + ret = self.cmd(cmd, kwds) + File "/home/cleber/src/qemu/python/qemu/qmp.py", line 278, in cmd + return self.cmd_obj(qmp_cmd) + File "/home/cleber/src/qemu/python/qemu/qmp.py", line 256, in cmd_obj + self.__sock.sendall(json.dumps(qmp_cmd).encode('utf-8')) +BrokenPipeError: [Errno 32] Broken pipe + +The qemu-system-sparc binary outputs: + + qemu-system-sparc: warning: nic lance.0 has no peer + qemu-system-sparc: Missing section footer for sysbusespscsi + qemu-system-sparc: load of migration failed: Invalid argument \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1923689 b/results/classifier/gemma3:12b/hypervisor/1923689 new file mode 100644 index 00000000..1cb946b4 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1923689 @@ -0,0 +1,81 @@ + +sig-abort / coredump observed from aio_ctx_finalize + +Observing occasional sig-abort based on v5.2.0 (tag) of QEMU. The VMM is configured for Kata use case, launching with a nvdimm/pmem based rootfs, and a set of workloads which are heavily utilizing virtio-fs. + +Sample qemu-cmdline: +/usr/bin/qemu-kata-system-x86_64 +-name sandbox-9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c +-uuid cd58d78d-ad44-4d26-9eab-66efab3fb23b +-machine pc,accel=kvm,kernel_irqchip,nvdimm=on +-cpu host,pmu=off +-qmp unix:/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/qmp.sock,server,nowait +-m 2048M,slots=10,maxmem=386381M +-device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= +-device virtio-serial-pci,disable-modern=false,id=serial0,romfile=,max_ports=2 +-device virtconsole,chardev=charconsole0,id=console0 +-chardev socket,id=charconsole0,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/console.sock,server,nowait +-device nvdimm,id=nv0,memdev=mem0 +-object memory-backend-file,id=mem0,mem-path=/usr/share/kata-containers/kata-containers.img,size=536870912 +-object rng-random,id=rng0,filename=/dev/urandom +-device virtio-rng-pci,rng=rng0,romfile= +-device vhost-vsock-pci,disable-modern=false,vhostfd=3,id=vsock-3054067214,guest-cid=3054067214,romfile= +-chardev socket,id=char-770bb156466e8ed5,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/vhost-fs.sock +-device vhost-user-fs-pci,chardev=char-770bb156466e8ed5,tag=kataShared,romfile= +-netdev tap,id=network-0,vhost=on,vhostfds=4,fds=5 +-device driver=virtio-net-pci,netdev=network-0,mac=9e:ad:0c:d1:58:e0,disable-modern=false,mq=on,vectors=4,romfile= +-rtc base=utc,driftfix=slew,clock=host +-global kvm-pit.lost_tick_policy=discard +-vga none +-no-user-config +-nodefaults +-nographic +--no-reboot +-daemonize +-object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on +-numa node,memdev=dimm1 +-kernel /usr/share/kata-containers/vmlinuz +-append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=32 systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket +-pidfile /run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/pid +-smp 1,cores=1,threads=1,sockets=32,maxcpus=32 + +From the core file I was able to obtain a backtrace: + +``` +(gdb) info thread + Id Target Id Frame + 6 Thread 0x7f92feffd700 (LWP 14678) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 5 Thread 0x7f92fffff700 (LWP 13860) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 4 Thread 0x7f930dcff700 (LWP 13572) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 3 Thread 0x7f92ff7fe700 (LWP 14179) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 2 Thread 0x7f93aed03700 (LWP 13565) 0x00007f93b20bfd19 in syscall () from /lib64/libc.so.6 +* 1 Thread 0x7f93c718dcc0 (LWP 13564) 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +(gdb) bt trace +No symbol table is loaded. Use the "file" command. +(gdb) bt +#0 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +#1 0x00007f93b1ffeac8 in abort () from /lib64/libc.so.6 +#2 0x00007f93b1ff61a6 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00007f93b1ff6252 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000007c6955 in aio_ctx_finalize () +#5 0x00007f93c64223d1 in g_source_unref_internal () from /lib64/libglib-2.0.so.0 +#6 0x00007f93c64225f5 in g_source_iter_next () from /lib64/libglib-2.0.so.0 +#7 0x00007f93c642362d in g_main_context_unref () from /lib64/libglib-2.0.so.0 +#8 0x00007f93c6425628 in g_main_loop_unref () from /lib64/libglib-2.0.so.0 +#9 0x00000000006dbaa0 in iothread_instance_finalize () +#10 0x00000000006c01e9 in object_unref () +#11 0x00000000006be647 in object_property_del_child () +#12 0x000000000075ad79 in monitor_cleanup () +#13 0x0000000000630635 in qemu_cleanup () +#14 0x000000000040fed3 in main () +``` + +I *think* we're hitting this assert: https://github.com/qemu/qemu/blob/master/util/async.c#L339 based on +``` +(gdb) up +#4 0x00000000007c6955 in aio_ctx_finalize () +``` + +The error is relatively infrequent, but a catastrophic core dump none the less. + +Please let me know if there's more I can pull from the core, or more info I can share to help facilitate debugging this error. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1924 b/results/classifier/gemma3:12b/hypervisor/1924 new file mode 100644 index 00000000..04eda4f9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1924 @@ -0,0 +1,67 @@ + +memory leak for pthread_create by valgrind +Description of problem: +qemu_thread_create calls pthread_create have memory leak +valgrind stack +``` +==4075190== 1,776 bytes in 3 blocks are possibly lost in loss record 6,778 of 6,978 +==4075190== at 0x4C3721A: calloc (vg_replace_malloc.c:760) +==4075190== by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so) +==4075190== by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so) +==4075190== by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581) +==4075190== by 0x9C470C: do_spawn_thread (thread-pool.c:145) +==4075190== by 0x9C47C0: worker_thread (thread-pool.c:82) +==4075190== by 0x9AFD89: qemu_thread_start (qemu-thread-posix.c:541) +==4075190== by 0xADA3149: start_thread (in /usr/lib64/libpthread-2.28.so) +==4075190== by 0xB0B7DC2: clone (in /usr/lib64/libc-2.28.so) +==4075190== +==4075190== 2,368 bytes in 4 blocks are possibly lost in loss record 6,834 of 6,978 +==4075190== at 0x4C3721A: calloc (vg_replace_malloc.c:760) +==4075190== by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so) +==4075190== by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so) +==4075190== by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581) +==4075190== by 0x827FA8: kvm_start_vcpu_thread (kvm-accel-ops.c:75) +==4075190== by 0x633672: qemu_init_vcpu (cpus.c:642) +==4075190== by 0x722EA7: x86_cpu_realizefn (cpu.c:7430) +==4075190== by 0x833E2E: device_set_realized (qdev.c:510) +==4075190== by 0x8371D5: property_set_bool (object.c:2299) +==4075190== by 0x839512: object_property_set (object.c:1434) +==4075190== by 0x83C58E: object_property_set_qobject (qom-qobject.c:28) +==4075190== by 0x839783: object_property_set_bool (object.c:1503) +``` + +If we do vcpu hotplug and hot unplug for virtual machine continuously, the virtual memory and RES memory of qemu is increasing. +Steps to reproduce: +1. start qemu： +valgrind --tool=memcheck --leak-check=full /home/qemu-system-x86_64 -accel kvm -cpu host -m 4G -smp 4,maxcpus=64,sockets=8,dies=1,cores=8,threads=1 -drive file=/home/centosx861.qcow2,if=none,id=drive0,cache=none -device virtio-blk,drive=drive0,bootindex=1 -monitor stdio -vnc :0 +2. after boot successful +ctl+c kill qemu + +``` +==4075190== 1,776 bytes in 3 blocks are possibly lost in loss record 6,778 of 6,978 +==4075190== at 0x4C3721A: calloc (vg_replace_malloc.c:760) +==4075190== by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so) +==4075190== by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so) +==4075190== by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581) +==4075190== by 0x9C470C: do_spawn_thread (thread-pool.c:145) +==4075190== by 0x9C47C0: worker_thread (thread-pool.c:82) +==4075190== by 0x9AFD89: qemu_thread_start (qemu-thread-posix.c:541) +==4075190== by 0xADA3149: start_thread (in /usr/lib64/libpthread-2.28.so) +==4075190== by 0xB0B7DC2: clone (in /usr/lib64/libc-2.28.so) +==4075190== +==4075190== 2,368 bytes in 4 blocks are possibly lost in loss record 6,834 of 6,978 +==4075190== at 0x4C3721A: calloc (vg_replace_malloc.c:760) +==4075190== by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so) +==4075190== by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so) +==4075190== by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581) +==4075190== by 0x827FA8: kvm_start_vcpu_thread (kvm-accel-ops.c:75) +==4075190== by 0x633672: qemu_init_vcpu (cpus.c:642) +==4075190== by 0x722EA7: x86_cpu_realizefn (cpu.c:7430) +==4075190== by 0x833E2E: device_set_realized (qdev.c:510) +==4075190== by 0x8371D5: property_set_bool (object.c:2299) +==4075190== by 0x839512: object_property_set (object.c:1434) +==4075190== by 0x83C58E: object_property_set_qobject (qom-qobject.c:28) +==4075190== by 0x839783: object_property_set_bool (object.c:1503) +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/1931 b/results/classifier/gemma3:12b/hypervisor/1931 new file mode 100644 index 00000000..98c2fb99 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1931 @@ -0,0 +1,4 @@ + +dbus: Support multiple QEMU instances +Additional information: +cc @marcandre.lureau diff --git a/results/classifier/gemma3:12b/hypervisor/1956 b/results/classifier/gemma3:12b/hypervisor/1956 new file mode 100644 index 00000000..f48a7895 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1956 @@ -0,0 +1,2 @@ + +[x86,microvm] Update microvm documentation with ACPI option diff --git a/results/classifier/gemma3:12b/hypervisor/1969 b/results/classifier/gemma3:12b/hypervisor/1969 new file mode 100644 index 00000000..8c7fdefa --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1969 @@ -0,0 +1,2 @@ + +Test fails with SIGSEGV because of use-after-free diff --git a/results/classifier/gemma3:12b/hypervisor/1970563 b/results/classifier/gemma3:12b/hypervisor/1970563 new file mode 100644 index 00000000..bcaf445e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1970563 @@ -0,0 +1,6 @@ + +Qemu 1:6.2+dfsg-2ubuntu6 deadlock bug + +There is a known bug that will cause VM deadlock, the patch should be merged and released: + +https://gitlab.com/qemu-project/qemu/-/commit/1dbbe6f172810026c51dc84ed927a3cc23017949#841723aa93098d8ab3b5068795e10ae7cf2a3179 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1974 b/results/classifier/gemma3:12b/hypervisor/1974 new file mode 100644 index 00000000..11e3fdbd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1974 @@ -0,0 +1,2 @@ + +Default console changes break Xen command-line diff --git a/results/classifier/gemma3:12b/hypervisor/1994002 b/results/classifier/gemma3:12b/hypervisor/1994002 new file mode 100644 index 00000000..2bf1494e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1994002 @@ -0,0 +1,24 @@ + +[SRU] migration was active, but no RAM info was set + +While live-migrating many instances concurrently, libvirt sometimes return internal error: migration was active, but no RAM info was set: +~~~ +2022-03-30 06:08:37.197 7 WARNING nova.virt.libvirt.driver [req-5c3296cf-88ee-4af6-ae6a-ddba99935e23 - - - - -] [instance: af339c99-1182-4489-b15c-21e52f50f724] Error monitoring migration: internal error: migration was active, but no RAM info was set: libvirt.libvirtError: internal error: migration was active, but no RAM info was set +~~~ + +From upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2074205 + +[Impact] + + * Effects of this bug are mostly observed in large scale clusters with a lot of live migration activity. + * Has second order effects for consumers of migration monitor such as libvirt and openstack. + +[Test Case] +Steps to Reproduce: +1. live evacuate a compute +2. live migration of one or more instances fails with the above error + +N.B Due to the nature of this bug it is difficult consistently reproduce. + +[Where problems could occur] + * In the event of a regression the migration monitor may report an inconsistent state. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/2027 b/results/classifier/gemma3:12b/hypervisor/2027 new file mode 100644 index 00000000..fab31308 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2027 @@ -0,0 +1,234 @@ + +Go runtime panic with qemu-x86_64-static on aarch64 (bisected) +Description of problem: +I have run into some crashes with certain x86 Go binaries running on arm64 (Asahi Linux) using qemu-user-static. The issue is also reproducible on current master (9c74490bff6c8886a922008d0c9ce6cae70dd17e). I have bisected the issue to commit 2d708164e0475064e0e2167bd73e8570e22df1e0: + +``` +first bad commit: [2d708164e0475064e0e2167bd73e8570e22df1e0] linux-user: Define TASK_UNMAPPED_BASE in $guest/target_mman.h +``` +Steps to reproduce: +1. Build example Go program `GOARCH=amd64 go build -o crashing .` +2. Run it with `qemu-x86_64-static ./crashing` + +<details><summary>Go program to reproduce</summary> + +```go +package main + +import "crypto/x509" + +func main() { + x509.SystemCertPool() +} +``` + +</details> +Additional information: +<details><summary>Go program stacktrace</summary> + +``` +runtime: lfstack.push invalid packing: node=0xffff3c3a9780 cnt=0x1 packed=0xffff3c3a97800001 -> node=0xffffffff3c3a9780 +fatal error: lfstack.push + +runtime stack: +runtime.throw({0x52cb61?, 0x2ce5?}) + /usr/lib/golang/src/runtime/panic.go:1077 +0x5c fp=0xc000613f08 sp=0xc000613ed8 pc=0x433d5c +runtime.(*lfstack).push(0xa0000000002?, 0xffffffffffffefe8?) + /usr/lib/golang/src/runtime/lfstack.go:29 +0x125 fp=0xc000613f48 sp=0xc000613f08 pc=0x40ac25 +runtime.(*spanSetBlockAlloc).free(...) + /usr/lib/golang/src/runtime/mspanset.go:322 +runtime.(*spanSet).reset(0x64d220) + /usr/lib/golang/src/runtime/mspanset.go:264 +0x79 fp=0xc000613f78 sp=0xc000613f48 pc=0x42ef79 +runtime.finishsweep_m() + /usr/lib/golang/src/runtime/mgcsweep.go:260 +0x95 fp=0xc000613fb8 sp=0xc000613f78 pc=0x423455 +runtime.gcStart.func2() + /usr/lib/golang/src/runtime/mgc.go:687 +0xf fp=0xc000613fc8 sp=0xc000613fb8 pc=0x45bd8f +traceback: unexpected SPWRITE function runtime.systemstack +runtime.systemstack() + /usr/lib/golang/src/runtime/asm_amd64.s:509 +0x4a fp=0xc000613fd8 sp=0xc000613fc8 pc=0x46016a + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/lib/golang/src/runtime/asm_amd64.s:474 +0x8 fp=0xc0001bb9f0 sp=0xc0001bb9e0 pc=0x460108 +runtime.gcStart({0xc000600000?, 0x98370?, 0x307800?}) + /usr/lib/golang/src/runtime/mgc.go:686 +0x2e5 fp=0xc0001bba88 sp=0xc0001bb9f0 pc=0x418e05 +runtime.mallocgc(0x98370, 0x50bb80, 0x1) + /usr/lib/golang/src/runtime/malloc.go:1242 +0x76f fp=0xc0001bbaf0 sp=0xc0001bba88 pc=0x40caaf +runtime.makeslice(0xc0001840a8?, 0x26?, 0x0?) + /usr/lib/golang/src/runtime/slice.go:103 +0x49 fp=0xc0001bbb18 sp=0xc0001bbaf0 pc=0x449729 +os.ReadFile({0xc00035a0f0?, 0x52dcd6?}) + /usr/lib/golang/src/os/file.go:738 +0xe5 fp=0xc0001bbbf0 sp=0xc0001bbb18 pc=0x49ed25 +crypto/x509.loadSystemRoots() + /usr/lib/golang/src/crypto/x509/root_unix.go:70 +0x3d4 fp=0xc0001bbcd8 sp=0xc0001bbbf0 pc=0x4fdef4 +crypto/x509.initSystemRoots() + /usr/lib/golang/src/crypto/x509/root.go:30 +0x5c fp=0xc0001bbd10 sp=0xc0001bbcd8 pc=0x4fd9fc +sync.(*Once).doSlow(0x1?, 0xb30000c00018ada0?) + /usr/lib/golang/src/sync/once.go:74 +0xbf fp=0xc0001bbd70 sp=0xc0001bbd10 pc=0x467bff +sync.(*Once).Do(...) + /usr/lib/golang/src/sync/once.go:65 +crypto/x509.systemRootsPool() + /usr/lib/golang/src/crypto/x509/root.go:21 +0x45 fp=0xc0001bbdc0 sp=0xc0001bbd70 pc=0x4fd8a5 +crypto/x509.SystemCertPool() + /usr/lib/golang/src/crypto/x509/cert_pool.go:112 +0x25 fp=0xc0001bbf30 sp=0xc0001bbdc0 pc=0x4f6705 +main.main() + /home/cyrill/dev/goruntime-crash/main.go:6 +0xf fp=0xc0001bbf40 sp=0xc0001bbf30 pc=0x4ff18f +runtime.main() + /usr/lib/golang/src/runtime/proc.go:267 +0x2bb fp=0xc0001bbfe0 sp=0xc0001bbf40 pc=0x43673b +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0001bbfe8 sp=0xc0001bbfe0 pc=0x461f61 + +goroutine 2 [force gc (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004efa8 sp=0xc00004ef88 pc=0x436b8e +runtime.goparkunlock(...) + /usr/lib/golang/src/runtime/proc.go:404 +runtime.forcegchelper() + /usr/lib/golang/src/runtime/proc.go:322 +0xb3 fp=0xc00004efe0 sp=0xc00004efa8 pc=0x436a13 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004efe8 sp=0xc00004efe0 pc=0x461f61 +created by runtime.init.6 in goroutine 1 + /usr/lib/golang/src/runtime/proc.go:310 +0x1a + +goroutine 3 [GC sweep wait]: +runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004f778 sp=0xc00004f758 pc=0x436b8e +runtime.goparkunlock(...) + /usr/lib/golang/src/runtime/proc.go:404 +runtime.bgsweep(0x0?) + /usr/lib/golang/src/runtime/mgcsweep.go:321 +0xdf fp=0xc00004f7c8 sp=0xc00004f778 pc=0x4235bf +runtime.gcenable.func1() + /usr/lib/golang/src/runtime/mgc.go:200 +0x25 fp=0xc00004f7e0 sp=0xc00004f7c8 pc=0x418945 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004f7e8 sp=0xc00004f7e0 pc=0x461f61 +created by runtime.gcenable in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:200 +0x66 + +goroutine 4 [GC scavenge wait]: +runtime.gopark(0xc00006c000?, 0x570658?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004ff70 sp=0xc00004ff50 pc=0x436b8e +runtime.goparkunlock(...) + /usr/lib/golang/src/runtime/proc.go:404 +runtime.(*scavengerState).park(0x625680) + /usr/lib/golang/src/runtime/mgcscavenge.go:425 +0x49 fp=0xc00004ffa0 sp=0xc00004ff70 pc=0x420e49 +runtime.bgscavenge(0x0?) + /usr/lib/golang/src/runtime/mgcscavenge.go:658 +0x59 fp=0xc00004ffc8 sp=0xc00004ffa0 pc=0x4213f9 +runtime.gcenable.func2() + /usr/lib/golang/src/runtime/mgc.go:201 +0x25 fp=0xc00004ffe0 sp=0xc00004ffc8 pc=0x4188e5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004ffe8 sp=0xc00004ffe0 pc=0x461f61 +created by runtime.gcenable in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:201 +0xa5 + +goroutine 17 [finalizer wait]: +runtime.gopark(0x400000?, 0x10004e670?, 0x0?, 0x0?, 0x654640?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004e628 sp=0xc00004e608 pc=0x436b8e +runtime.runfinq() + /usr/lib/golang/src/runtime/mfinal.go:193 +0x107 fp=0xc00004e7e0 sp=0xc00004e628 pc=0x4179c7 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004e7e8 sp=0xc00004e7e0 pc=0x461f61 +created by runtime.createfing in goroutine 1 + /usr/lib/golang/src/runtime/mfinal.go:163 +0x3d + +goroutine 18 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004a750 sp=0xc00004a730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004a7e0 sp=0xc00004a750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004a7e8 sp=0xc00004a7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 19 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004af50 sp=0xc00004af30 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004afe0 sp=0xc00004af50 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004afe8 sp=0xc00004afe0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 33 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090750 sp=0xc000090730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc0000907e0 sp=0xc000090750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0000907e8 sp=0xc0000907e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 20 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004b750 sp=0xc00004b730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004b7e0 sp=0xc00004b750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004b7e8 sp=0xc00004b7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 49 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00008c750 sp=0xc00008c730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00008c7e0 sp=0xc00008c750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00008c7e8 sp=0xc00008c7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 21 [GC worker (idle)]: +runtime.gopark(0xa740c76b8ab?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004bf50 sp=0xc00004bf30 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004bfe0 sp=0xc00004bf50 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004bfe8 sp=0xc00004bfe0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 22 [GC worker (idle)]: +runtime.gopark(0xa740cc9dc5e?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004c750 sp=0xc00004c730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004c7e0 sp=0xc00004c750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004c7e8 sp=0xc00004c7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 23 [GC worker (idle)]: +runtime.gopark(0x654640?, 0x1?, 0xba?, 0x5f?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004cf50 sp=0xc00004cf30 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004cfe0 sp=0xc00004cf50 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004cfe8 sp=0xc00004cfe0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 24 [GC worker (idle)]: +runtime.gopark(0xa740c58ec16?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004d750 sp=0xc00004d730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004d7e0 sp=0xc00004d750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004d7e8 sp=0xc00004d7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 34 [GC worker (idle)]: +runtime.gopark(0x654640?, 0x1?, 0x7a?, 0xa3?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090f50 sp=0xc000090f30 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc000090fe0 sp=0xc000090f50 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc000090fe8 sp=0xc000090fe0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c +exit status 2 +``` + +</details> diff --git a/results/classifier/gemma3:12b/hypervisor/2030 b/results/classifier/gemma3:12b/hypervisor/2030 new file mode 100644 index 00000000..dcd13809 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2030 @@ -0,0 +1,18 @@ + +Unreachable code +Description of problem: +There is always a false condition in the function `alloc_code_gen_buffer_splitwx_memfd` in the file `tcg/region.c`. If `buf_rw == NULL` we go to the mark __fail__: + +https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/region.c?ref_type=heads#L580-L583 + +But the value of `buf_rx` is __`MAP_FAILED`__: + +https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/region.c?ref_type=heads#L577 + +And this line will never be reached: + +https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/region.c?ref_type=heads#L601 + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Voronin. diff --git a/results/classifier/gemma3:12b/hypervisor/2034 b/results/classifier/gemma3:12b/hypervisor/2034 new file mode 100644 index 00000000..e0a309c2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2034 @@ -0,0 +1,9 @@ + +ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu)) +Description of problem: +``` +cat boot.log +aarch64>** +aarch64>ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu)) +aarch64>Bail out! ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu)) +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2042 b/results/classifier/gemma3:12b/hypervisor/2042 new file mode 100644 index 00000000..85e5f950 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2042 @@ -0,0 +1,19 @@ + +Not able to reboot Linux guest on Windows host +Description of problem: +I am running Linux Mint on Windows, but when I try to reboot the machine, I get the following error: + +qemu: WHPX: Unexpected VP exit code 4 + +I did some experiments changing the flags I use when I launch Qemu and I realized that if I set -smp 1 it does not fail. Furthermore, if I set the irqchip to off (kernel-irqchip=off) it does not fail either, but both options do not have good performance at all. I realized too that if I set 4 cores (-smp 4), the error might appear up to 4 times. + +What seems to be failing then is the APIC emulation that Hyper-V provides. Does anyone know if: + +1. Am I missing a flag when launching Qemu? +2. Is it there a patch to solve this? + +Any leads for solving this problem would be highly appreciated. +Steps to reproduce: +1. Install MSYS +2. Open MSYS and run pacman -S mingw-w64-x86_64-qemu +3. Launch Qemu and reboot machine diff --git a/results/classifier/gemma3:12b/hypervisor/2047 b/results/classifier/gemma3:12b/hypervisor/2047 new file mode 100644 index 00000000..a0a078b8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2047 @@ -0,0 +1,4 @@ + +Support of LibVF.IO - vendor neutral GPU multiplexing tool driven by YAML & VFIO. +Additional information: +Git: https://github.com/Arc-Compute/LibVF.IO/tree/master/ diff --git a/results/classifier/gemma3:12b/hypervisor/2054 b/results/classifier/gemma3:12b/hypervisor/2054 new file mode 100644 index 00000000..4128e23e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2054 @@ -0,0 +1,43 @@ + +chacha20-s390 broken in 8.2.0 in TCG on s390x +Description of problem: +When running linux guest in qemu-system-s390x in TCG mode, it fails at selftests of crypto algorithms, namely at chacha20: +``` +[ 10.546690] alg: skcipher: chacha20-s390 encryption test failed (wrong result) on test vector 1, cfg="in-place (one sglist)" +[ 10.546914] alg: self-tests for chacha20 using chacha20-s390 failed (rc=-22) +[ 10.546969] ------------[ cut here ]------------ +[ 10.546998] alg: self-tests for chacha20 using chacha20-s390 failed (rc=-22) +[ 10.547182] WARNING: CPU: 1 PID: 109 at crypto/testmgr.c:5936 alg_test+0x55a/0x5b8 +[ 10.547510] Modules linked in: net_failover chacha_s390(+) libchacha virtio_blk(+) failover +[ 10.547854] CPU: 1 PID: 109 Comm: cryptomgr_test Not tainted 6.5.0-5-s390x #1 Debian 6.5.13-1 +[ 10.548002] Hardware name: QEMU 8561 QEMU (KVM/Linux) +[ 10.548101] Krnl PSW : 0704c00180000000 00000000005df8fe (alg_test+0x55e/0x5b8) +[ 10.548207] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 +[ 10.548291] Krnl GPRS: 0000000000000000 0000000001286408 00000000005df8fa 0000000001286408 +[ 10.548337] 000000000014bf14 00000000001c6ba8 0000000001838b3c 0000000000000005 +[ 10.548475] 00000000025a4880 00000000025a4800 ffffffffffffffea 00000000ffffffea +[ 10.548521] 000000003e649200 00000000ffffffff 00000000005df8fa 000003800016bcf8 +[ 10.549504] Krnl Code: 00000000005df8ee: c020003b5828 larl %r2,0000000000d4a93e +[ 10.549504] 00000000005df8f4: c0e5ffdb62d2 brasl %r14,000000000014be98 +[ 10.549504] #00000000005df8fa: af000000 mc 0,0 +[ 10.549504] >00000000005df8fe: a7f4fee6 brc 15,00000000005df6ca +[ 10.549504] 00000000005df902: b9040042 lgr %r4,%r2 +[ 10.549504] 00000000005df906: b9040039 lgr %r3,%r9 +[ 10.549504] 00000000005df90a: c020003b57df larl %r2,0000000000d4a8c8 +[ 10.549504] 00000000005df910: 18bd lr %r11,%r13 +[ 10.550004] Call Trace: +[ 10.550375] [<00000000005df8fe>] alg_test+0x55e/0x5b8 +[ 10.550467] ([<00000000005df8fa>] alg_test+0x55a/0x5b8) +[ 10.550489] [<00000000005d9fbc>] cryptomgr_test+0x34/0x60 +[ 10.550514] [<000000000017d004>] kthread+0x124/0x130 +[ 10.550539] [<0000000000103124>] __ret_from_fork+0x3c/0x50 +[ 10.550562] [<0000000000b1dfca>] ret_from_fork+0xa/0x30 +[ 10.550611] Last Breaking-Event-Address: +[ 10.550626] [<000000000014bf20>] __warn_printk+0x88/0x110 +[ 10.550723] ---[ end trace 0000000000000000 ]--- +``` +An interesting issue here - it does not happen on, say, amd64 host running qemu-system-s390x, but happens on s390x host. I haven't tried other hosts though. + +Bisection points at v8.1.0-2627-gab84dc398b commit, "tcg/optimize: Optimize env memory operations". + +https://lore.kernel.org/qemu-devel/d5e8f88b-1d19-4e00-8dc2-b20e0cd34931@tls.msk.ru/T/#u is the original report on qemu-devel. diff --git a/results/classifier/gemma3:12b/hypervisor/2072 b/results/classifier/gemma3:12b/hypervisor/2072 new file mode 100644 index 00000000..de779e86 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2072 @@ -0,0 +1,2 @@ + +Regression in 8.2: Synchronous Exception when running a VM on AArch64 diff --git a/results/classifier/gemma3:12b/hypervisor/2086 b/results/classifier/gemma3:12b/hypervisor/2086 new file mode 100644 index 00000000..a266a355 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2086 @@ -0,0 +1,16 @@ + +qemu-img created VMDK files lead to "Unsupported or invalid disk type 7" on ESXi +Description of problem: +Trying to start the VM using vmdk converted with qemu-img fails with + +Failed to start the virtual machine. +Module DevicePowerOn power on failed. +Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' +Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported. +Steps to reproduce: +1. Convert booting OS (in both Qemu and VMWare with the help of drivers) to vmdk +2. Push vmdk file to ESXi datastore +3. Try to boot + +Additional information: +ESXi seem to use a specific implementation of vmdk, with a *name*.vmdk file being the descriptor of the virtual disk and a *name*-flat.vmdk. diff --git a/results/classifier/gemma3:12b/hypervisor/2108 b/results/classifier/gemma3:12b/hypervisor/2108 new file mode 100644 index 00000000..2f07be52 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2108 @@ -0,0 +1,2 @@ + +ppc64 POWER10 machine-check caused by ifetch crashes qemu diff --git a/results/classifier/gemma3:12b/hypervisor/2115 b/results/classifier/gemma3:12b/hypervisor/2115 new file mode 100644 index 00000000..385fc15b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2115 @@ -0,0 +1,55 @@ + +HVF accelerator crash in vmx_write_mem (mmu_gva_to_gpa) +Description of problem: +During the installation of Windows 2000 from CD-ROM (image), following disk initialization/formatting, a base operating system is copied to the (virtual) hard disk and the system is rebooted. During the start from hard disk to resume installation, QEMU crashes. + +This crash occurs whether using installation media for Windows 2000 Professional or Windows 2000 Advanced Server. It can be reproduced before any product key or Terminal Services licensing information is entered. + +Undertaking the same process with TCG accelerator on the same host, the issue is not observed. + +Unlike in #1603, `-pdpe1gb` does not work around this crash. +Steps to reproduce: +1. In HVF QEMU accelerator on x86_64 macOS, start up a pc-i440fx virtual machine w/ Windows 2000 (SP4) installation media. +2. Initialize/format a (qcow2-powered) hard drive as NTFS when prompted. +3. Allow the system to reboot. +Additional information: +Crash stderr: +``` +vmx_write_mem: mmu_gva_to_gpa bfd391f0 failed +<pid> Abort trap: 6 +``` +(it's always "bfd391f0") + +Stacktrace: +``` +0 libsystem_kernel.dylib 0x7ff8164771e2 __pthread_kill + 10 +1 libsystem_pthread.dylib 0x7ff8164aeee6 pthread_kill + 263 +2 libsystem_c.dylib 0x7ff8163d5b45 abort + 123 +3 qemu-system-x86_64 0x106a3d98d vmx_write_mem + 190 +4 qemu-system-x86_64 0x106a39f1c write_val_ext + 88 +5 qemu-system-x86_64 0x106a3cb1c exec_movs_single + 92 +6 qemu-system-x86_64 0x106a3c412 exec_movs + 61 +7 qemu-system-x86_64 0x106a3b35e exec_instruction + 48 +8 qemu-system-x86_64 0x106a36707 hvf_vcpu_exec + 2411 +9 qemu-system-x86_64 0x106b16532 hvf_cpu_thread_fn + 283 +10 qemu-system-x86_64 0x106c752fc qemu_thread_start + 130 +11 libsystem_pthread.dylib 0x7ff8164af1d3 _pthread_start + 125 +12 libsystem_pthread.dylib 0x7ff8164aabd3 thread_start + 15 +``` + +Registers at crash: +``` +rax: 0x0000000000000000 rbx: 0x000070000322d000 rcx: 0x000070000322cc58 rdx: 0x0000000000000000 +rdi: 0x0000000000001103 rsi: 0x0000000000000006 rbp: 0x000070000322cc80 rsp: 0x000070000322cc58 + r8: 0x00007ff859b93d08 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000246 +r12: 0x0000000000001103 r13: 0x0000000000000000 r14: 0x0000000000000006 r15: 0x0000000000000016 +rip: 0x00007ff8164771e2 rfl: 0x0000000000000246 cr2: 0x0000000000000000 +``` + +OS response: +**Exception Type:** EXC_CRASH (SIGABRT) +**Exception Codes:** 0x0000000000000000, 0x0000000000000000 +**Termination Reason:** Namespace SIGNAL, Code 6 Abort trap: 6 +**Logical CPU:** 0 +**Error Code:** 0x02000148 +**Trap Number:** 133 diff --git a/results/classifier/gemma3:12b/hypervisor/2124 b/results/classifier/gemma3:12b/hypervisor/2124 new file mode 100644 index 00000000..496d8166 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2124 @@ -0,0 +1,2 @@ + +Use watchdog_perform_action() for watchdogs currently using qemu_system_reset_request() diff --git a/results/classifier/gemma3:12b/hypervisor/2127 b/results/classifier/gemma3:12b/hypervisor/2127 new file mode 100644 index 00000000..0e824e36 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2127 @@ -0,0 +1,2 @@ + +test-aio-multithread.c:371:test_multi_fair_mutex: assertion failed (counter == atomic_counter): (316636 == 316637) diff --git a/results/classifier/gemma3:12b/hypervisor/2142 b/results/classifier/gemma3:12b/hypervisor/2142 new file mode 100644 index 00000000..d2643354 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2142 @@ -0,0 +1,2 @@ + +`-machine microvm -cpu host` crashes when guest attempts to check CPUID SGX bits diff --git a/results/classifier/gemma3:12b/hypervisor/2161 b/results/classifier/gemma3:12b/hypervisor/2161 new file mode 100644 index 00000000..53081062 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2161 @@ -0,0 +1,2 @@ + +warnings when building lockstep plugin on s390 diff --git a/results/classifier/gemma3:12b/hypervisor/2169 b/results/classifier/gemma3:12b/hypervisor/2169 new file mode 100644 index 00000000..8588b9e2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2169 @@ -0,0 +1,394 @@ + +qemu-system-s390x crashes with s390_swap_bfp_rounding_mode: code should not be reached +Description of problem: +Ubuntu 23.10 was installed on a s390x emulated platform some time ago. The system was setup, an open source project was built and tested. The system rebooted several times. + +Several days later, qemu crashed while the command `apt update` was running in the guest. The error was: +``` +ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached +Bail out! ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached +Abort trap: 6 +``` + +Now, each time the virtual machine is booted, qemu immediately crashes all the time at the end of the boot with the same error. The virtual machine is no longer usable. +Steps to reproduce: +1. Run the above command. +2. It crashes at the end of the boot. +Additional information: +The disk image `disk.qcow2` is 3.7 GB large, too large to be attached here. + +Full boot log: +``` +qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -nographic \ + -drive file=disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none \ + -device virtio-blk-ccw,devno=fe.0.0002,drive=drive-virtio-disk0,bootindex=1 \ + -nic user,hostfwd=tcp::2222-:22 +LOADPARM=[ ] +Using virtio-blk. +Using SCSI scheme. +......... +KASLR disabled: CPU has no PRNG +KASLR disabled: CPU has no PRNG +[ 0.561037] Linux version 6.5.0-14-generic (buildd@bos02-s390x-003) (s390x-linux-gnu-gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.41) #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 (Ubuntu 6.5.0-14.14-generic 6.5.3) +[ 0.562868] setup: Linux is running under KVM in 64-bit mode +[ 0.601125] setup: The maximum memory size is 8192MB +[ 0.601577] setup: Relocating AMODE31 section of size 0x00003000 +[ 0.603756] cpu: 8 configured CPUs, 0 standby CPUs +[ 34.401410] Write protected kernel read-only data: 22272k +[ 34.548843] Zone ranges: +[ 34.548873] DMA [mem 0x0000000000000000-0x000000007fffffff] +[ 34.549570] Normal [mem 0x0000000080000000-0x00000001ffffffff] +[ 34.549609] Movable zone start for each node +[ 34.549633] Early memory node ranges +[ 34.549664] node 0: [mem 0x0000000000000000-0x00000001ffffffff] +[ 34.549979] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff] +[ 34.619124] percpu: Embedded 31 pages/cpu s87552 r8192 d31232 u126976 +[ 34.621042] Kernel command line: root=/dev/disk/by-path/ccw-0.0.0002-part1 +[ 34.622253] random: crng init done +[ 34.624460] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) +[ 34.625511] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) +[ 34.626568] Fallback order for Node 0: 0 +[ 34.627026] Built 1 zonelists, mobility grouping on. Total pages: 2064384 +[ 34.627069] Policy zone: Normal +[ 34.627356] mem auto-init: stack:all(zero), heap alloc:on, heap free:off +[ 34.669390] Memory: 8169740K/8388608K available (14780K kernel code, 3496K rwdata, 7492K rodata, 6376K init, 1312K bss, 218868K reserved, 0K cma-reserved) +[ 34.677279] SLUB: HWalign=256, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 +[ 34.678165] ftrace: allocating 38640 entries in 151 pages +[ 34.967308] ftrace: allocated 151 pages with 5 groups +[ 34.977052] rcu: Hierarchical RCU implementation. +[ 34.977093] rcu: RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=8. +[ 34.977196] Rude variant of Tasks RCU enabled. +[ 34.977209] Tracing variant of Tasks RCU enabled. +[ 34.977329] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. +[ 34.977360] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 +[ 35.023854] NR_IRQS: 3, nr_irqs: 3, preallocated irqs: 3 +[ 35.026445] rcu: srcu_init: Setting srcu_struct sizes based on contention. +[ 35.027768] clocksource: tod: mask: 0xffffffffffffffff max_cycles: 0x3b0a9be803b0a9, max_idle_ns: 1805497147909793 ns +[ 35.032313] Console: colour dummy device 80x25 +[ 35.036054] printk: console [ttysclp0] enabled +[ 35.038867] pid_max: default: 32768 minimum: 301 +[ 35.044407] LSM: initializing lsm=lockdown,capability,landlock,yama,apparmor,integrity +[ 35.044879] landlock: Up and running. +[ 35.044911] Yama: becoming mindful. +[ 35.046994] AppArmor: AppArmor initialized +[ 35.048281] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 35.048366] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 35.079199] RCU Tasks Rude: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1. +[ 35.079584] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1. +[ 35.081422] rcu: Hierarchical SRCU implementation. +[ 35.081465] rcu: Max phase no-delay instances is 1000. +[ 35.087248] smp: Bringing up secondary CPUs ... +[ 35.109842] smp: Brought up 1 node, 8 CPUs +[ 35.133520] devtmpfs: initialized +[ 35.143534] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 35.143848] futex hash table entries: 2048 (order: 7, 524288 bytes, linear) +[ 35.155409] NET: Registered PF_NETLINK/PF_ROUTE protocol family +[ 35.158309] audit: initializing netlink subsys (disabled) +[ 35.160126] audit: type=2000 audit(1708008415.080:1): state=initialized audit_enabled=0 res=1 +[ 35.162149] Spectre V2 mitigation: execute trampolines +[ 35.218877] iommu: Default domain type: Translated +[ 35.218963] iommu: DMA domain TLB invalidation policy: strict mode +[ 35.221010] SCSI subsystem initialized +[ 35.221925] pps_core: LinuxPPS API ver. 1 registered +[ 35.221953] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 35.233495] NetLabel: Initializing +[ 35.233538] NetLabel: domain hash size = 128 +[ 35.233569] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 35.234452] NetLabel: unlabeled traffic allowed by default +[ 35.490582] VFS: Disk quotas dquot_6.6.0 +[ 35.490828] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) +[ 35.492088] hugetlbfs: disabling because there are no supported hugepage sizes +[ 35.494605] AppArmor: AppArmor Filesystem Enabled +[ 35.537129] NET: Registered PF_INET protocol family +[ 35.538412] IP idents hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 35.553748] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4, 65536 bytes, linear) +[ 35.554033] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) +[ 35.554241] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear) +[ 35.555185] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear) +[ 35.555971] TCP: Hash tables configured (established 65536 bind 65536) +[ 35.558027] MPTCP token hash table entries: 8192 (order: 5, 196608 bytes, linear) +[ 35.558386] UDP hash table entries: 4096 (order: 5, 131072 bytes, linear) +[ 35.558715] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes, linear) +[ 35.560408] NET: Registered PF_UNIX/PF_LOCAL protocol family +[ 35.560888] NET: Registered PF_XDP protocol family +[ 35.566276] Trying to unpack rootfs image as initramfs... +[ 35.583376] kvm-s390: SIE is not available +[ 35.584037] hypfs: The hardware system does not support hypfs +[ 35.686516] Initialise system trusted keyrings +[ 35.688015] Key type blacklist registered +[ 35.689131] workingset: timestamp_bits=45 max_order=21 bucket_order=0 +[ 35.689516] zbud: loaded +[ 35.693314] squashfs: version 4.0 (2009/01/31) Phillip Lougher +[ 35.695879] fuse: init (API version 7.38) +[ 35.699171] integrity: Platform Keyring initialized +[ 35.808827] Key type asymmetric registered +[ 35.808973] Asymmetric key parser 'x509' registered +[ 35.809365] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248) +[ 35.810660] io scheduler mq-deadline registered +[ 35.816790] hvc_iucv: The z/VM IUCV HVC device driver cannot be used without z/VM +[ 35.846919] loop: module loaded +[ 35.851530] tun: Universal TUN/TAP device driver, 1.6 +[ 35.853032] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log. +[ 35.853186] device-mapper: uevent: version 1.0.3 +[ 35.854080] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@redhat.com +[ 35.854360] drop_monitor: Initializing network drop monitor service +[ 35.963712] NET: Registered PF_INET6 protocol family +[ 36.335556] Freeing initrd memory: 23592K +[ 36.587317] Segment Routing with IPv6 +[ 36.587633] In-situ OAM (IOAM) with IPv6 +[ 36.588291] NET: Registered PF_PACKET protocol family +[ 36.589147] Key type dns_resolver registered +[ 36.590364] cio: Channel measurement facility initialized using format extended (mode autodetected) +[ 36.592594] sclp_sd: Store Data request failed (eq=2, di=3, response=0x40f0, flags=0x00, status=0, rc=-5) +[ 36.593406] ap: The hardware system does not support AP instructions +[ 36.599059] virtio_blk virtio0: 1/0/0 default/read/poll queues +[ 36.604778] virtio_blk virtio0: [vda] 62914560 512-byte logical blocks (32.2 GB/30.0 GiB) +[ 36.621065] registered taskstats version 1 +[ 36.623865] vda: vda1 +[ 36.630114] Loading compiled-in X.509 certificates +[ 36.639995] Loaded X.509 cert 'Build time autogenerated kernel key: ffca65de79457ba2128edde155db56e4bec9b799' +[ 36.642859] Loaded X.509 cert 'Canonical Ltd. Live Patch Signing: 14df34d1a87cf37625abec039ef2bf521249b969' +[ 36.646267] Loaded X.509 cert 'Canonical Ltd. Kernel Module Signing: 88f752e560a1e0737e31163a466ad7b70a850c19' +[ 36.646336] blacklist: Loading compiled-in revocation X.509 certificates +[ 36.647551] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0' +[ 36.647791] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2017): 242ade75ac4a15e50d50c84b0d45ff3eae707a03' +[ 36.648026] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (ESM 2018): 365188c1d374d6b07c3c8f240f8ef722433d6a8b' +[ 36.648252] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2019): c0746fd6c5da3ae827864651ad66ae47fe24b3e8' +[ 36.648455] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v1): a8d54bbb3825cfb94fa13c9f8a594a195c107b8d' +[ 36.648669] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v2): 4cf046892d6fd3c9a5b03f98d845f90851dc6a8c' +[ 36.648876] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v3): 100437bb6de6e469b581e61cd66bce3ef4ed53af' +[ 36.649092] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (Ubuntu Core 2019): c1d57b8f6b743f23ee41f4f7ee292f06eecadfb9' +[ 36.679176] Key type .fscrypt registered +[ 36.679250] Key type fscrypt-provisioning registered +[ 36.788001] Key type encrypted registered +[ 36.788125] AppArmor: AppArmor sha1 policy hashing enabled +[ 36.788580] ima: No TPM chip found, activating TPM-bypass! +[ 36.788676] Loading compiled-in module X.509 certificates +[ 36.791454] Loaded X.509 cert 'Build time autogenerated kernel key: ffca65de79457ba2128edde155db56e4bec9b799' +[ 36.791525] ima: Allocated hash algorithm: sha1 +[ 36.793195] ima: No architecture policies found +[ 36.793649] evm: Initialising EVM extended attributes: +[ 36.793691] evm: security.selinux +[ 36.793729] evm: security.SMACK64 +[ 36.793751] evm: security.SMACK64EXEC +[ 36.793772] evm: security.SMACK64TRANSMUTE +[ 36.793792] evm: security.SMACK64MMAP +[ 36.793817] evm: security.apparmor +[ 36.793837] evm: security.ima +[ 36.793857] evm: security.capability +[ 36.793882] evm: HMAC attrs: 0x1 +[ 36.814426] Freeing unused kernel image (initmem) memory: 6376K +[ 36.855771] Write protected read-only-after-init data: 144k +[ 38.034069] Checked W+X mappings: passed, no unexpected W+X pages found +[ 38.034295] Run /init as init process +Loading, please wait... +Starting systemd-udevd version 253.5-1ubuntu6.1 +[ 41.012145] virtio_net virtio1 enc0: renamed from eth0 +Begin: Starting firmware auto-configuration ... done. +Begin: Loading essential drivers ... [ 48.602928] raid6: vx128x8 gen() 3084 MB/s +[ 48.603058] raid6: using algorithm vx128x8 gen() 3084 MB/s +[ 48.773302] raid6: .... xor() 1800 MB/s, rmw enabled +[ 48.773433] raid6: using s390xc recovery algorithm +[ 48.783956] xor: automatically using best checksumming function xc +done. +Begin: Running /scripts/init-premount ... done. +Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. +Begin: Running /scripts/local-premount ... [ 49.837645] Btrfs loaded, zoned=yes, fsverity=yes +Scanning for Btrfs filesystems +done. +Begin: Will now check root file system ... fsck from util-linux 2.39.1 +[/usr/sbin/fsck.ext4 (1) -- /dev/vda1] fsck.ext4 -a -C0 /dev/vda1 +/dev/vda1: recovering journal +/dev/vda1: clean, 123948/1966080 files, 1902224/7863808 blocks +done. +[ 50.624887] EXT4-fs (vda1): mounted filesystem b33ae246-95a1-494e-b967-9ab636fd714d ro with ordered data mode. Quota mode: none. +done. +Begin: Running /scripts/local-bottom ... done. +Begin: Running /scripts/init-bottom ... done. +[ 52.531666] systemd[1]: systemd 253.5-1ubuntu6.1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) +[ 52.531979] systemd[1]: Detected virtualization kvm. +[ 52.532228] systemd[1]: Detected architecture s390x. + +Welcome to Ubuntu 23.10! + +[ 52.545927] systemd[1]: Hostname set to <vms390x>. +[ 52.738383] systemd[1]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set +[ 54.251527] (sd-execu[322]: /usr/lib/systemd/system-generators/s390-cpi-vars failed with exit status 1. +[ 56.207233] systemd[1]: Queued start job for default target graphical.target. +[ 56.324910] systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe. +[ OK ] Created slice system-modpr…lice - Slice /system/modprobe. +[ 56.342133] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty. +[ OK ] Created slice system-seria… - Slice /system/serial-getty. +[ 56.354987] systemd[1]: Created slice user.slice - User and Session Slice. +[ OK ] Created slice user.slice - User and Session Slice. +[ 56.359125] systemd[1]: Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch. +[ OK ] Started systemd-ask-passwo… Requests to Wall Directory Watch. +[ 56.370074] systemd[1]: Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point. +[ OK ] Set up automount proc-sys-…rmats File System Automount Point. +[ 56.373118] systemd[1]: Reached target integritysetup.target - Local Integrity Protected Volumes. +[ OK ] Reached target integrityse…Local Integrity Protected Volumes. +[ 56.374764] systemd[1]: Reached target slices.target - Slice Units. +[ OK ] Reached target slices.target - Slice Units. +[ 56.375999] systemd[1]: Reached target snapd.mounts-pre.target - Mounting snaps. +[ OK ] Reached target snapd.mounts-pre.target - Mounting snaps. +[ 56.377421] systemd[1]: Reached target veritysetup.target - Local Verity Protected Volumes. +[ OK ] Reached target veritysetup… - Local Verity Protected Volumes. +[ 56.381860] systemd[1]: Listening on dm-event.socket - Device-mapper event daemon FIFOs. +[ OK ] Listening on dm-event.sock… Device-mapper event daemon FIFOs. +[ 56.388375] systemd[1]: Listening on lvm2-lvmpolld.socket - LVM2 poll daemon socket. +[ OK ] Listening on lvm2-lvmpolld…ket - LVM2 poll daemon socket. +[ 56.394056] systemd[1]: Listening on multipathd.socket - multipathd control socket. +[ OK ] Listening on multipathd.so…t - multipathd control socket. +[ 56.399560] systemd[1]: Listening on syslog.socket - Syslog Socket. +[ OK ] Listening on syslog.socket - Syslog Socket. +[ 56.404487] systemd[1]: Listening on systemd-fsckd.socket - fsck to fsckd communication Socket. +[ OK ] Listening on systemd-fsckd…sck to fsckd communication Socket. +[ 56.407621] systemd[1]: Listening on systemd-initctl.socket - initctl Compatibility Named Pipe. +[ OK ] Listening on systemd-initc… initctl Compatibility Named Pipe. +[ 56.414642] systemd[1]: Listening on systemd-journald-dev-log.socket - Journal Socket (/dev/log). +[ OK ] Listening on systemd-journ…t - Journal Socket (/dev/log). +[ 56.421162] systemd[1]: Listening on systemd-journald.socket - Journal Socket. +[ OK ] Listening on systemd-journald.socket - Journal Socket. +[ 56.429706] systemd[1]: Listening on systemd-networkd.socket - Network Service Netlink Socket. +[ OK ] Listening on systemd-netwo… - Network Service Netlink Socket. +[ 56.436982] systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket. +[ OK ] Listening on systemd-udevd….socket - udev Control Socket. +[ 56.443136] systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket. +[ OK ] Listening on systemd-udevd…l.socket - udev Kernel Socket. +[ 56.450850] systemd[1]: dev-hugepages.mount - Huge Pages File System was skipped because of an unmet condition check (ConditionPathExists=/sys/kernel/mm/hugepages). +[ 56.516995] systemd[1]: Mounting dev-mqueue.mount - POSIX Message Queue File System... + Mounting dev-mqueue.mount…OSIX Message Queue File System... +[ 56.554312] systemd[1]: Mounting sys-kernel-debug.mount - Kernel Debug File System... + Mounting sys-kernel-debug.… - Kernel Debug File System... +[ 56.589207] systemd[1]: Mounting sys-kernel-tracing.mount - Kernel Trace File System... + Mounting sys-kernel-tracin… - Kernel Trace File System... +[ 56.651284] systemd[1]: Starting systemd-journald.service - Journal Service... + Starting systemd-journald.service - Journal Service... +[ 56.683040] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout... + Starting keyboard-setup.se…Set the console keyboard layout... +[ 56.729933] systemd[1]: Starting kmod-static-nodes.service - Create List of Static Device Nodes... + Starting kmod-static-nodes…ate List of Static Device Nodes... +[ 56.765378] systemd[1]: Starting lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling... + Starting lvm2-monitor.serv…ng dmeventd or progress polling... +[ 56.768638] systemd[1]: lxd-agent.service - LXD - agent was skipped because of an unmet condition check (ConditionPathExists=/dev/virtio-ports/org.linuxcontainers.lxd). +[ 56.806941] systemd[1]: Starting modprobe@configfs.service - Load Kernel Module configfs... + Starting modprobe@configfs…m - Load Kernel Module configfs... +[ 56.852266] systemd[1]: Starting modprobe@dm_mod.service - Load Kernel Module dm_mod... + Starting modprobe@dm_mod.s…[0m - Load Kernel Module dm_mod... +[ 56.907919] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... + Starting modprobe@drm.service - Load Kernel Module drm... +[ 56.962524] systemd[1]: Starting modprobe@efi_pstore.service - Load Kernel Module efi_pstore... + Starting modprobe@efi_psto…- Load Kernel Module efi_pstore... +[ 57.014414] systemd[1]: Starting modprobe@fuse.service - Load Kernel Module fuse... + Starting modprobe@fuse.ser…e - Load Kernel Module fuse... +[ 57.069081] systemd-journald[352]: Collecting audit messages is disabled. +[ 57.076472] systemd[1]: Starting modprobe@loop.service - Load Kernel Module loop... + Starting modprobe@loop.ser…e - Load Kernel Module loop... +[ 57.085874] systemd[1]: netplan-ovs-cleanup.service - OpenVSwitch configuration for cleanup was skipped because of an unmet condition check (ConditionFileIsExecutable=/usr/bin/ovs-vsctl). +[ 57.095668] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root). +[ 57.168905] systemd[1]: Starting systemd-modules-load.service - Load Kernel Modules... + Starting systemd-modules-l…rvice - Load Kernel Modules... +[ 57.226498] systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems... + Starting systemd-remount-f…nt Root and Kernel File Systems... +[ 57.287754] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices... + Starting systemd-udev-trig…[0m - Coldplug All udev Devices... +[ 57.419867] systemd[1]: Mounted dev-mqueue.mount - POSIX Message Queue File System. +[ OK ] Mounted dev-mqueue.mount…OSIX Message Queue File System. +[ 57.432129] systemd[1]: Mounted sys-kernel-debug.mount - Kernel Debug File System. +[ OK ] Mounted sys-kernel-debug.m…nt - Kernel Debug File System. +[ 57.443392] systemd[1]: Mounted sys-kernel-tracing.mount - Kernel Trace File System. +[ OK ] Mounted sys-kernel-tracing…nt - Kernel Trace File System. +[ 57.455168] systemd[1]: Finished kmod-static-nodes.service - Create List of Static Device Nodes. +[ OK ] Finished kmod-static-nodes…reate List of Static Device Nodes. +[ 57.466903] systemd[1]: Started systemd-journald.service - Journal Service. +[ OK ] Started systemd-journald.service - Journal Service. +[ OK ] Finished modprobe@configfs…[0m - Load Kernel Module configfs. +[ 57.555558] EXT4-fs (vda1): re-mounted b33ae246-95a1-494e-b967-9ab636fd714d r/w. Quota mode: none. +[ OK ] Finished modprobe@dm_mod.s…e - Load Kernel Module dm_mod. +[ OK ] Finished modprobe@efi_psto…m - Load Kernel Module efi_pstore. +[ OK ] Finished modprobe@fuse.service - Load Kernel Module fuse. +[ OK ] Finished modprobe@loop.service - Load Kernel Module loop. +[ OK ] Finished systemd-modules-l…service - Load Kernel Modules. +[ OK ] Finished systemd-remount-f…ount Root and Kernel File Systems. + Activating swap swap.img.swap - /swap.img... + Mounting sys-fs-fuse-conne… - FUSE Control File System... +[ 57.885897] Adding 4085756k swap on /swap.img. Priority:-2 extents:7 across:4388860k FS + Mounting sys-kernel-config…ernel Configuration File System... + Starting multipathd.servic…per Multipath Device Controller... + Starting systemd-journal-f…h Journal to Persistent Storage... + Starting systemd-random-se… - Load/Save OS Random Seed... + Starting systemd-sysctl.se…ce - Apply Kernel Variables... + Starting systemd-sysusers.…rvice - Create System Users... +[ OK ] Activated swap swap.img.swap - /swap.img. +[ 58.206094] systemd-journald[352]: Received client request to flush runtime journal. +[ 58.228283] systemd-journald[352]: File /var/log/journal/accea1250e0f4fe291f8c3b31e7720d7/system.journal corrupted or uncleanly shut down, renaming and replacing. +[ OK ] Finished lvm2-monitor.serv…sing dmeventd or progress polling. +[ OK ] Finished modprobe@drm.service - Load Kernel Module drm. +[ OK ] Mounted sys-fs-fuse-connec…nt - FUSE Control File System. +[ OK ] Mounted sys-kernel-config.… Kernel Configuration File System. +[ OK ] Finished systemd-random-se…ce - Load/Save OS Random Seed. +[ OK ] Finished systemd-sysctl.service - Apply Kernel Variables. +[ OK ] Reached target swap.target - Swaps. +[ OK ] Finished systemd-sysusers.service - Create System Users. + Starting systemd-tmpfiles-…ate Static Device Nodes in /dev... +[ OK ] Finished systemd-journal-f…ush Journal to Persistent Storage. +[ OK ] Finished keyboard-setup.se…- Set the console keyboard layout. +[ OK ] Started multipathd.service…apper Multipath Device Controller. +[ OK ] Finished systemd-tmpfiles-…reate Static Device Nodes in /dev. +[ OK ] Reached target local-fs-pr…reparation for Local File Systems. + Mounting snap-core22-865.m…t unit for core22, revision 865... + Mounting snap-lxd-25850.mo…nt unit for lxd, revision 25850... + Mounting snap-snapd-20294.… unit for snapd, revision 20294... + Mounting snap-snapd-20676.… unit for snapd, revision 20676... + Starting systemd-udevd.ser…ger for Device Events and Files... +[ OK ] Mounted snap-core22-865.mo…unt unit for core22, revision 865. +[ OK ] Mounted snap-lxd-25850.mou…ount unit for lxd, revision 25850. +[ OK ] Mounted snap-snapd-20294.m…nt unit for snapd, revision 20294. +[ OK ] Mounted snap-snapd-20676.m…nt unit for snapd, revision 20676. +[ OK ] Reached target snapd.mounts.target - Mounted snaps. +[ OK ] Reached target local-fs.target - Local File Systems. + Starting apparmor.service - Load AppArmor profiles... + Starting console-setup.ser…m - Set console font and keymap... + Starting finalrd.service…me dir for shutdown pivot root... + Starting plymouth-read-wri…mouth To Write Out Runtime Data... + Starting systemd-binfmt.se…et Up Additional Binary Formats... + Starting systemd-tmpfiles-… Volatile Files and Directories... + Starting ufw.service - Uncomplicated firewall... +[ OK ] Finished systemd-udev-trig…e - Coldplug All udev Devices. +[ OK ] Finished console-setup.ser…[0m - Set console font and keymap. +[ OK ] Finished finalrd.service…time dir for shutdown pivot root. +[ OK ] Finished plymouth-read-wri…lymouth To Write Out Runtime Data. +[ OK ] Finished ufw.service - Uncomplicated firewall. +[ OK ] Reached target network-pre…get - Preparation for Network. + Mounting proc-sys-fs-binfm…utable File Formats File System... +[ OK ] Mounted proc-sys-fs-binfmt…ecutable File Formats File System. +[ OK ] Finished systemd-binfmt.se… Set Up Additional Binary Formats. +[ OK ] Started systemd-udevd.serv…nager for Device Events and Files. +[ OK ] Started systemd-ask-passwo…quests to Console Directory Watch. +[ OK ] Reached target cryptsetup.…get - Local Encrypted Volumes. + Starting systemd-networkd.…ice - Network Configuration... +[ OK ] Finished systemd-tmpfiles-…te Volatile Files and Directories. + Starting systemd-resolved.…e - Network Name Resolution... + Starting systemd-timesyncd… - Network Time Synchronization... + Starting systemd-update-ut…rd System Boot/Shutdown in UTMP... +[ OK ] Finished systemd-update-ut…cord System Boot/Shutdown in UTMP. +[ OK ] Found device dev-ttysclp0.device - /dev/ttysclp0. +[ OK ] Started systemd-networkd.service - Network Configuration. + Starting systemd-networkd-…it for Network to be Configured... +[ OK ] Started systemd-timesyncd.…0m - Network Time Synchronization. +[ OK ] Reached target time-set.target - System Time Set. +[ OK ] Finished systemd-networkd-…Wait for Network to be Configured. +[ OK ] Finished apparmor.service - Load AppArmor profiles. + Starting snapd.apparmor.se…les managed internally by snapd... +[ OK ] Started systemd-resolved.s…ice - Network Name Resolution. +[ OK ] Reached target network.target - Network. +[ OK ] Reached target network-online.target - Network is Online. +[ OK ] Reached target nss-lookup.…m - Host and Network Name Lookups. +[ OK ] Reached target remote-fs-p…eparation for Remote File Systems. +[ OK ] Reached target remote-fs.target - Remote File Systems. +[ OK ] Finished blk-availability.…m - Availability of block devices. +** +ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached +Bail out! ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached +Abort trap: 6 +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2173 b/results/classifier/gemma3:12b/hypervisor/2173 new file mode 100644 index 00000000..2268aef9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2173 @@ -0,0 +1,2 @@ + +Disable CPU dirty region tracking on Xen + Arm64 where xen migration is not supported. diff --git a/results/classifier/gemma3:12b/hypervisor/2176 b/results/classifier/gemma3:12b/hypervisor/2176 new file mode 100644 index 00000000..5ae32a96 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2176 @@ -0,0 +1,2 @@ + +Events delivered during Capabilities Negotiation mode diff --git a/results/classifier/gemma3:12b/hypervisor/2187 b/results/classifier/gemma3:12b/hypervisor/2187 new file mode 100644 index 00000000..7f6c167a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2187 @@ -0,0 +1,2 @@ + +system/cpu: deadlock in pause_all_vcpus() diff --git a/results/classifier/gemma3:12b/hypervisor/219 b/results/classifier/gemma3:12b/hypervisor/219 new file mode 100644 index 00000000..ba6ce2dd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/219 @@ -0,0 +1,2 @@ + +Request A Port of QEMU to UWP for xbox dev mode diff --git a/results/classifier/gemma3:12b/hypervisor/2195 b/results/classifier/gemma3:12b/hypervisor/2195 new file mode 100644 index 00000000..f921febd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2195 @@ -0,0 +1,40 @@ + +qemu-system-x86_64 : cannot resume from S3 suspend for Q35 + OVMF +Description of problem: +There is a specific configuration where the resume from S3 does not work: + +- Q35 machine + OVMF.fd (https://retrage.github.io/edk2-nightly/) +- TCG acceleration (it works when --accel=kvm is set) + +The output at resume is: + +``` +!!!! X64 Exception Type - 05(#BR - BOUND Range Exceeded) CPU Apic ID - 00000000 !!!! +RIP - 0000000000006237, CS - 0000000000000028, RFLAGS - 0000000000000002 +RAX - 0000000080000027, RCX - 0000000000000000, RDX - 0000000000000000 +RBX - 0000000099200000, RSP - 000000000FF96236, RBP - 000000000FF96320 +RSI - 000000000F74E000, RDI - 0000000000833F31 +R8 - 0000002800000000, R9 - 0000000000000000, R10 - 000000000FF968F0 +R11 - 0000000000828B30, R12 - 000000000FF9ACD0, R13 - 000000000F76B000 +R14 - 000000000F76A000, R15 - 0000000000000000 +DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 +GS - 0000000000000030, SS - 0000000000000030 +CR0 - 0000000080000033, CR2 - 0000000000000000, CR3 - 000000000F75B000 +CR4 - 0000000000000668, CR8 - 0000000000000000 +DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 +DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 +GDTR - 0000000000833DE0 0000000000000047, LDTR - 0000000000000000 +IDTR - 000000000FF97D70 000000000000021F, TR - 0000000000000000 +FXSAVE_STATE - 000000000FF95E90 +!!!! Can't find image information. !!!! +``` + +After bisecting, this is caused by commit : 18a536f1f8d6222e562f59179e837fdfd8b92718 If i revert this comment, the resume works nicely. + +I used a script to generate a tiny initrd to test but i think the problem can be reproduced with any guest kernel + rootfs. I also verify that this problem can be reproduced with different host kernels (6.5) than the one i used (6.8) +Steps to reproduce: +1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img +2. Run qemu and drop into shell +3. Put machine into S3 (echo mem \> /sys/power/state) +4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup) +5. The machine does not resume correctly diff --git a/results/classifier/gemma3:12b/hypervisor/222 b/results/classifier/gemma3:12b/hypervisor/222 new file mode 100644 index 00000000..8e0b050f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/222 @@ -0,0 +1,2 @@ + +Reading /proc/self/task/<pid>/maps is not remapped to the target diff --git a/results/classifier/gemma3:12b/hypervisor/2226 b/results/classifier/gemma3:12b/hypervisor/2226 new file mode 100644 index 00000000..e9ccac29 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2226 @@ -0,0 +1,57 @@ + +arm HSTR trap settings routed to EL1 instead of EL2 +Description of problem: +ARM's HSTR register is used to trap CP15 access from EL1/0. qemu's implementation seems to be inconsistent with ARM's documentation. + +Take the system register VBAR for example, the following pseudo code is grabbed from ARM DDI 0487J.a ID042523 G8-10651, which is the logics behind when reading VBAR. +``` +if PSTATE.EL == EL0 then + UNDEFINED; +elsif PSTATE.EL == EL1 then + if EL2Enabled() && !ELUsingAArch32(EL2) && HSTR_EL2.T12 == '1' then + AArch64.AArch32SystemAccessTrap(EL2, 0x03); + elsif EL2Enabled() && ELUsingAArch32(EL2) && HSTR.T12 == '1' then + AArch32.TakeHypTrapException(0x03); + elsif HaveEL(EL3) && ELUsingAArch32(EL3) then + R[t] = VBAR_NS; + else + R[t] = VBAR; +elsif PSTATE.EL == EL2 then + if HaveEL(EL3) && ELUsingAArch32(EL3) then + R[t] = VBAR_NS; + else + R[t] = VBAR; +elsif PSTATE.EL == EL3 then + if SCR.NS == '0' then + R[t] = VBAR_S; + else + R[t] = VBAR_NS; +``` + +The main logics in my attached test program are: +1. Setting EL2 and EL1's exception table +2. Set HSTR.T12 +3. ERET to EL1, and read VBAR from EL1 + +As the document mentions, when CPU running on EL1 && HSTR.T12 is set, HypTrapException 0x3 should be taken, which is EL2. But the test program shows, on such circumstances, CPU is being routed to EL1's undefined exception. +Steps to reproduce: +1. Clone this repo https://github.com/roolrz/reproduce-qemu-arm-hstr-issue +2. Use make to build the test program +3. Use following command to launch it +``` +qemu-system-arm \ + -nographic \ + -cpu cortex-a7 \ + -M virt,virtualization=on \ + -m 1G \ + -kernel el2.elf +``` +4. The following message is printed by the program, problem reproduced +``` +EL2 Booted +Jumping to el1 +el1 reached, triggering trap +EL1 undefined sync triggered +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2238 b/results/classifier/gemma3:12b/hypervisor/2238 new file mode 100644 index 00000000..74454581 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2238 @@ -0,0 +1,48 @@ + +The `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` is not properly honored +Description of problem: +The `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` is not properly honored. +Steps to reproduce: +1. Register a callback with `qemu_plugin_register_vcpu_mem_cb()` +2. In the callback, print the return of `qemu_plugin_mem_is_store()` (either `true` or `false`) +3. Change the value of `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` and look whether the callback prints `true` and/or `false` to determine if this is inline with `rw`. + +In the callback, we don't we get what we asked for. + +| Requested with rw | Observed in the callback | +|---------------------|----------------------------| +| QEMU_PLUGIN_MEM_R | Only writes | +| QEMU_PLUGIN_MEM_W | Both reads and writes | +| QEMU_PLUGIN_MEM_RW | Both reads and writes | +Additional information: +In `plugin-gen.c`, line 497, there is the following function: + +```cpp +static bool op_rw(const TCGOp *op, const struct qemu_plugin_dyn_cb *cb) +{ + int w; + + w = op->args[2]; + return !!(cb->rw & (w + 1)); +} +``` + +The issue described above seems to be caused by the `+ 1`. I removed it and got the expected results. + +This function is used in the same file, line 526, like this: + +```cpp + if (!ok(begin_op, cb)) { + continue; + } +``` + +This isn't consistent with `core.c`, line 509, where the same flag is checked like this: + +```cpp + if (!(rw & cb->rw)) { + break; + } +``` + +Inconsistent because of the `+1` and also because of `break`/`continue`. diff --git a/results/classifier/gemma3:12b/hypervisor/2240 b/results/classifier/gemma3:12b/hypervisor/2240 new file mode 100644 index 00000000..5fd10d7a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2240 @@ -0,0 +1,5 @@ + +Please provide useful defaults for machine and cpu +Additional information: +See https://bugs.debian.org/1040212 and https://salsa.debian.org/helmutg/debvm/-/issues/15 for the preceding discussion and +https://salsa.debian.org/helmutg/debvm/-/blob/main/bin/debvm-run and https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/80 for the used machine and cpu values. diff --git a/results/classifier/gemma3:12b/hypervisor/2246 b/results/classifier/gemma3:12b/hypervisor/2246 new file mode 100644 index 00000000..456a9044 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2246 @@ -0,0 +1,2 @@ + +ppc_hv_tests.py:HypervisorTest.test_hv_pseries test fails if xorriso is not present rather than skipping diff --git a/results/classifier/gemma3:12b/hypervisor/2256 b/results/classifier/gemma3:12b/hypervisor/2256 new file mode 100644 index 00000000..7b438ca1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2256 @@ -0,0 +1,2 @@ + +cirrus CI jobs failing diff --git a/results/classifier/gemma3:12b/hypervisor/2270 b/results/classifier/gemma3:12b/hypervisor/2270 new file mode 100644 index 00000000..e4992dcc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2270 @@ -0,0 +1,2 @@ + +CPU topology recognition for Ryzen 9 7950X3D diff --git a/results/classifier/gemma3:12b/hypervisor/2277 b/results/classifier/gemma3:12b/hypervisor/2277 new file mode 100644 index 00000000..a2207dde --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2277 @@ -0,0 +1,2 @@ + +COarse-grained LOck-stepping Virtual Machines for Non-stop Service Encountered Assertion Error diff --git a/results/classifier/gemma3:12b/hypervisor/2287 b/results/classifier/gemma3:12b/hypervisor/2287 new file mode 100644 index 00000000..2973051f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2287 @@ -0,0 +1,30 @@ + +whpx, on booting win98, qemu crashes with Failed to emulate PortIO access with EmulatorReturnStatus: 2 +Description of problem: +Q) What is the correct command line arguments to boot win98se with ```accel whpx``` + +The above given command line crashes partway through the win98se boot process before the desktop shows up +``` +Windows Hypervisor Platform accelerator is operational +C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: warning: GLib-GIO: Failed to open application manifest `C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AppxManifest.xml' for package #34 (`Microsoft.MicrosoftEdge_44.19041.1266.0_neutral__8wekyb3d8bbwe'): error code 0x2 +C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: WHPX: Failed to emulate PortIO access with EmulatorReturnStatus: 2 +C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor +``` +Steps to reproduce: +1. Finish a complete win98 install using ```-machine type=pc,accel=tcg -cpu qemu64``` + ```qemu-system-x86_64 -machine type=pc,accel=tcg -cpu qemu64 -smp "sockets=1,cores=1,threads=1" -m 512 -nodefaults -bios bios-256k.bin -rtc base=localtime -display sdl,gl=on -device VGA,vgamem_mb=128 -audiodev dsound,id=snd1 -device adlib,audiodev=snd1 -audiodev dsound,id=snd2 -device ac97,audiodev=snd2 -boot c -drive index=0,if=ide,media=disk,format=vhdx,file="F:\Win98m40_sys.vhdx" -drive index=1,if=ide,media=disk,format=vhdx,file="F:\Win98m40_data_01.vhdx" -drive index=3,if=ide,media=disk,format=vhdx,file="F:\Win98m40_data_02.vhdx"``` + With all guestos-win98-drivers installed the win98 seems to work satisfactorily. + Using vga driver from https://github.com/JHRobotics/vmdisp9x/releases +2. now change processor to ```-cpu core2duo```, it boots . This does not seem to matter, bug exists even with qemu64 +3. now change accel to ```-machine type=pc,accel=whpx ```, qemu crashes partway into boot before bringing up desktop. + with or without ```kernel-irqchip=off``` does not matter + with or without cpu arguments ```,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-time``` also does not matter +4. Setting back to ```-machine type=pc,accel=tcg -cpu core2duo``` restores bootable win98se. +Additional information: +- [target/i386/whpx/whpx-all.c#L920](https://gitlab.com/qemu-project/qemu/-/blob/a12214d1c4204d2f51d8724993b8dfcf50dd7d94/target/i386/whpx/whpx-all.c#L920) +- The part of the OS bootsequence, which includes the Win98/DOS boot menu, scandisk, etc. works fine. Its possible to boot to DOS mode and run DOS commands. The crash happens when into the win.com Win98SE boot sequence just before it can bring up the GUI desktop. +- qemu crashes even if in the win98/DOS bootmenu, selection is made to boot into ```safe-mode```, which is supposed to boot a vanilla 16-color VGA desktop loading minimal drivers. As before, crash happens before GUI desktop is loaded. +- 20220623 Learn.Microsoft WHvEmulatorTryIoEmulation and WHvEmulatorTryMmioEmulation + https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatortryemulation +- 20220426 Learn.Microsoft WHV_EMULATOR_STATUS + https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatorstatus diff --git a/results/classifier/gemma3:12b/hypervisor/2290 b/results/classifier/gemma3:12b/hypervisor/2290 new file mode 100644 index 00000000..134c5b37 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2290 @@ -0,0 +1,144 @@ + +Wrong multiplication result of 'long double' on m68k +Description of problem: +In both x86 and m68k, 'long double' is an 80-bit format consisting of + - 1 bit sign, 15 bits exponent, + - 1 explicit 1 bit, 63 fraction bits. + +According to <https://en.wikipedia.org/wiki/Extended_precision> and +<https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf> table 1-6 (page 1-23), with two differences: + - In m68k, there are 16 zero bits as filler after the sign/exponent + word, so that the total size is 96 bits. + - In x86, the minimum exponent of normalized numbers is 1; + in m68k, the minimum exponent of normalized numbers is 0. + +The latter difference is reflected in the values of LDBL_MIN_EXP and +LDBL_MIN in gcc: + +In x86: +``` +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN_EXP_ +#define LDBL_MIN_EXP __LDBL_MIN_EXP__ +#define __LDBL_MIN_EXP__ (-16381) +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN__ +#define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L +#define LDBL_MIN __LDBL_MIN__ +``` +In m68k (I use Debian 12/Linux): +``` +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN_EXP_ +#define LDBL_MIN_EXP __LDBL_MIN_EXP__ +#define __LDBL_MIN_EXP__ (-16382) +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN__ +#define __LDBL_MIN__ 1.68105157155604675313e-4932L +#define LDBL_MIN __LDBL_MIN__ +``` +Steps to reproduce: +Take this program, foo.c: +``` +/* Show extended-precision https://en.wikipedia.org/wiki/Extended_precision + multiplication bug in QEMU. */ + +#include <stdio.h> + +static void +show (const long double *p) +{ +#ifdef __m68k__ + printf("<S,E: 0x%08X M: 0x%08X%08X>", + ((const unsigned int *) p)[0], + ((const unsigned int *) p)[1], + ((const unsigned int *) p)[2]); +#else /* x86 */ + printf("<S,E: 0x%04X M: 0x%08X%08X>", + ((const unsigned short *) p)[4], + ((const unsigned int *) p)[1], + ((const unsigned int *) p)[0]); +#endif + printf (" = %La = %Lg", *p, *p); +} + +static void +show_mult (long double a, long double b) +{ + printf ("Factors: "); + show (&a); + printf ("\n and: "); + show (&b); + long double c = a * b; + printf ("\nProduct: "); + show (&c); + printf ("\n\n"); +} + +/* Return 2^n. */ +static long double +pow2l (int n) +{ + int k = n; + volatile long double x = 1; + volatile long double y = 2; + /* Invariant: 2^n == x * y^k. */ + if (k < 0) + { + y = 0.5L; + k = - k; + } + while (k > 0) + { + if (k != 2 * (k / 2)) + { + x = x * y; + k = k - 1; + } + if (k == 0) + break; + y = y * y; + k = k / 2; + } + /* Now k == 0, hence x == 2^n. */ + return x; +} + +int main () +{ + show_mult (pow2l (-16382), 0.5L); + show_mult (pow2l (-16381), 0.25L); + return 0; +} +``` +Its output on x86: +``` +$ ./a.out +Factors: <S,E: 0x0001 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932 + and: <S,E: 0x3FFE M: 0x8000000000000000> = 0x8p-4 = 0.5 +Product: <S,E: 0x0000 M: 0x4000000000000000> = 0x4p-16385 = 1.68105e-4932 + +Factors: <S,E: 0x0002 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932 + and: <S,E: 0x3FFD M: 0x8000000000000000> = 0x8p-5 = 0.25 +Product: <S,E: 0x0000 M: 0x4000000000000000> = 0x4p-16385 = 1.68105e-4932 +``` +Its output on m68k: +``` +$ ./a.out +Factors: <S,E: 0x00010000 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932 + and: <S,E: 0x3FFE0000 M: 0x8000000000000000> = 0x8p-4 = 0.5 +Product: <S,E: 0x00000000 M: 0x4000000000000000> = 0x4p-16386 = 8.40526e-4933 + +Factors: <S,E: 0x00020000 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932 + and: <S,E: 0x3FFD0000 M: 0x8000000000000000> = 0x8p-5 = 0.25 +Product: <S,E: 0x00000000 M: 0x4000000000000000> = 0x4p-16386 = 8.40526e-4933 +``` +The product, computed by QEMU, is incorrect. It is only half as large as the +correct value. The expected output should be: +``` +Factors: <S,E: 0x00010000 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932 + and: <S,E: 0x3FFE0000 M: 0x8000000000000000> = 0x8p-4 = 0.5 +Product: <S,E: 0x00000000 M: 0x8000000000000000> = 0x8p-16386 = 1.68105e-4932 + +Factors: <S,E: 0x00020000 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932 + and: <S,E: 0x3FFD0000 M: 0x8000000000000000> = 0x8p-5 = 0.25 +Product: <S,E: 0x00000000 M: 0x8000000000000000> = 0x8p-16386 = 1.68105e-4932 +``` +Additional information: +In QEMU's source code, I would guess that this multiplication is performed by the `floatx80_mul` function. diff --git a/results/classifier/gemma3:12b/hypervisor/2294 b/results/classifier/gemma3:12b/hypervisor/2294 new file mode 100644 index 00000000..e0b19d45 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2294 @@ -0,0 +1,2 @@ + +x86 microvm machine stuck under Xen accelerator diff --git a/results/classifier/gemma3:12b/hypervisor/2295 b/results/classifier/gemma3:12b/hypervisor/2295 new file mode 100644 index 00000000..d5fa3e91 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2295 @@ -0,0 +1,5 @@ + +Support Apple Silicon acceleration for x86 / x86_64 guests +Additional information: +* [Top-level discussion on UTM downstream](https://github.com/utmapp/UTM/issues/5460) +* [Discussion on memory access instructions on UTM downstream](https://github.com/utmapp/UTM/issues/2366) diff --git a/results/classifier/gemma3:12b/hypervisor/2301 b/results/classifier/gemma3:12b/hypervisor/2301 new file mode 100644 index 00000000..34c9d00f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2301 @@ -0,0 +1,2 @@ + +GitLab Windows Server 2019 runner is deprecated diff --git a/results/classifier/gemma3:12b/hypervisor/2328 b/results/classifier/gemma3:12b/hypervisor/2328 new file mode 100644 index 00000000..6711ef00 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2328 @@ -0,0 +1,2 @@ + +sha1.c:161:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 0 diff --git a/results/classifier/gemma3:12b/hypervisor/233 b/results/classifier/gemma3:12b/hypervisor/233 new file mode 100644 index 00000000..26aad684 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/233 @@ -0,0 +1,2 @@ + +QEMU installer with WHPX support diff --git a/results/classifier/gemma3:12b/hypervisor/2339 b/results/classifier/gemma3:12b/hypervisor/2339 new file mode 100644 index 00000000..7b4f5a22 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2339 @@ -0,0 +1,2 @@ + +VM Crash is observed while deploying an ubuntu VM with OS version 18.04 on host with ubuntu version 24.04 diff --git a/results/classifier/gemma3:12b/hypervisor/2344 b/results/classifier/gemma3:12b/hypervisor/2344 new file mode 100644 index 00000000..54373be9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2344 @@ -0,0 +1,46 @@ + +Plugin scoreboard deadlock (plugin.lock vs start_exclusive) +Description of problem: +Deadlock + +In frame 9 the thread grabs the plugin.lock, and starts to wait for other cpus to enter exclusive idle. +``` +#7 0x00005555555a1295 in start_exclusive () at ../hw/core/cpu-common.c:199 +#8 plugin_grow_scoreboards__locked (cpu=0x7fff0c2b4720) at ../plugins/core.c:238 +#9 qemu_plugin_vcpu_init_hook (cpu=0x7fff0c2b4720) at ../plugins/core.c:258 +``` + +The other thread just finished a TB and do the callback to the plugin, so it will not become exclusive idle until it finishes. +That callback tries to create a new 'scoreboard', but plugin.lock is already taken. +``` +#7 qemu_plugin_scoreboard_new (element_size=element_size@entry=8) at ../plugins/api.c:464 +#8 0x00007ffff7fb973d in vcpu_tb_trans (id=<optimized out>, tb=0x555555858d60) at /home/rehn/source/qemu/contrib/plugins/hotblocks.c:125 +#9 0x00005555557394f1 in qemu_plugin_tb_trans_cb (cpu=<optimized out>, tb=0x555555858d60) at ../plugins/core.c:418 +``` + +Locally I'm using this fix, reverse order so we enter exclusive idle before grabbing the plugin.lock: +``` +diff --git a/plugins/core.c b/plugins/core.c +index 1e58a57bf1..0e41c4ef22 100644 +--- a/plugins/core.c ++++ b/plugins/core.c +@@ -236,4 +236,2 @@ static void plugin_grow_scoreboards__locked(CPUState *cpu) + +- /* cpus must be stopped, as tb might still use an existing scoreboard. */ +- start_exclusive(); + struct qemu_plugin_scoreboard *score; +@@ -244,3 +242,2 @@ static void plugin_grow_scoreboards__locked(CPUState *cpu) + tb_flush(cpu); +- end_exclusive(); + } +@@ -250,2 +247,4 @@ void qemu_plugin_vcpu_init_hook(CPUState *cpu) + bool success; ++ /* cpus must be stopped, as tb might still use an existing scoreboard. */ ++ start_exclusive(); + +@@ -259,2 +258,3 @@ void qemu_plugin_vcpu_init_hook(CPUState *cpu) + qemu_rec_mutex_unlock(&plugin.lock); ++ end_exclusive(); +``` +Steps to reproduce: +Run command a few times and get 'unlucky' diff --git a/results/classifier/gemma3:12b/hypervisor/235 b/results/classifier/gemma3:12b/hypervisor/235 new file mode 100644 index 00000000..a7e391b9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/235 @@ -0,0 +1,2 @@ + +atomic failure linking with --enable-sanitizers on 32-bit Linux hosts diff --git a/results/classifier/gemma3:12b/hypervisor/2354 b/results/classifier/gemma3:12b/hypervisor/2354 new file mode 100644 index 00000000..139a29c8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2354 @@ -0,0 +1,8 @@ + +Compile error with In function ‘vhost_scsi_set_workers’: +Steps to reproduce: +1. ./configure +2. ./make +Additional information: +I suspect something is misconfigured on my system, but I followed the straighforward directions +for building and I am running stock Debian 12. diff --git a/results/classifier/gemma3:12b/hypervisor/237 b/results/classifier/gemma3:12b/hypervisor/237 new file mode 100644 index 00000000..fba53110 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/237 @@ -0,0 +1,2 @@ + +[Feature request] x86: dump MSR features in human form diff --git a/results/classifier/gemma3:12b/hypervisor/2377 b/results/classifier/gemma3:12b/hypervisor/2377 new file mode 100644 index 00000000..4928078f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2377 @@ -0,0 +1,26 @@ + +Debootstrapping debian-bullseye arm64 segfaults with qemu >=8.1 +Steps to reproduce: +1. Use qemu >= 8.1 (version <= 8.0.x work well) +2. Install `debootstrap` package +3. Run `sudo debootstrap --arch=arm64 bullseye root11-arm64` + +This fails to chroot into the system being debootstrapped: + +``` +$ sudo debootstrap --arch=arm64 bullseye root11-arm64 +... +W: Failure trying to run: chroot "/home/3/root11" /sbin/ldconfig +W: See /home/3/root11/debootstrap/debootstrap.log for details +$ tail -n2 /home/3/root11/debootstrap/debootstrap.log +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +/usr/share/debootstrap/functions: line 1092: 3869 Segmentation fault chroot "/home/3/root11" "$@" +``` +Additional information: +Failure happens only when debootstrapping "bullseye" with "arm64" architecture. +Older (e.g. <= "buster") and newer (e.g. > "bookworm") distros are deboostrapped OK. +Other (e.g. "armhf" and others) architectures are debootstrapped OK. + +Qemu version <8.1 (e.g. 8.0.5 I use in Gentoo or versions in Debian <= bookworm) don't have the bug. + +Originally faced the issue with Gentoo host. Recently rechecked with Debian Trixie host. diff --git a/results/classifier/gemma3:12b/hypervisor/2395 b/results/classifier/gemma3:12b/hypervisor/2395 new file mode 100644 index 00000000..d01430ec --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2395 @@ -0,0 +1,61 @@ + +qemu-system-x86_64: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed when paused vm migrating (with shared storage) from dest to src host +Description of problem: +We are doing migration tests with share storage (nfs) as follows: +First, we pause the virtual machine using the 'virsh suspend'command, then migrate the virtual machine to the destination host by 'virsh migrate' command, and there is no problem. After the migration is complete, the virtual machine remains paused on the destination host. However, when we migrate the virtual machine back to the original host, an assertion error is triggered on the current host（dest host）: + +``` +705 qemu-system-x86_64: ../block.c:6748: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +706 2024-06-17 11:15:59.972+0000: shutting down, reason=crashed +``` + +and virsh migrate commant return error: +``` +**virsh migrate test qemu+tcp://host_ip/system tcp://host_ip --live --verbose --unsafe +Migration: [ 98 %]error: operation failed: domain is not running** +``` +Steps to reproduce: +1. We create an vm with shareable storage and then paused vm in source host: + ``` + virsh create test.xml running + virsh suspend test paused + ``` +2. Migrate vm to the destination host: + ``virsh migrate test qemu+tcp://dest_ip/system tcp://dest_ip --live --verbose --unsafe`` +3. In destination host，vm is paused. +4. Migrate vm back to the source host，and then migration failed and assert error in qemu log in destination host: + ``` + virsh migrate test qemu+tcp://host_ip/system tcp://host_ip --live --verbose --unsafe + Migration: [ 98 %]error: operation failed: domain is not running + ``` + ``` + 705 qemu-system-x86_64: ../block.c:6748: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & + BDRV_O_INACTIVE)' failed. + 706 2024-06-17 11:15:59.972+0000: shutting down, reason=crashed + ``` +Additional information: +1) src -----> dest + ``` +migration_thread() + migration_completion + global_state_store() + vm_stop_force_state(RUN_STATE_FINISH_MIGRATE) + qemu_savevm_state_complete_precopy_nop_iterable() + bdrv_inactivate_all () + bdrv_inactivate_recurse() + bs->open_flags |= BDRV_O_INACTIVE; (BDRV_O_INACTIVE=0x0800) +``` + +2) dest -----> src +``` +migration_thread() + qemu_savevm_state_complete_precopy_non_iterable() + bdrv_inactivate_all () + bdrv_inactivate_recurse() + assert(!(bs->open_flags & BDRV_O_INACTIVE)); Assert and Crash +``` + + +I'm not sure how to address this issue. If QEMU does not support such a migration, a gentler way would be to directly report an error and exit, just like what did in migrate_prepare function， instead of crash qemu. + +If you have any ideas, please let me know, thanks. diff --git a/results/classifier/gemma3:12b/hypervisor/2402 b/results/classifier/gemma3:12b/hypervisor/2402 new file mode 100644 index 00000000..03851b2e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2402 @@ -0,0 +1,25 @@ + +WHPX accelerator run with edk2 EFI fails to process the reboot signal from guest OS +Description of problem: +Qemu freezes any time WHPX-accelerated guest Windows 11 sends a reboot signal to Qemu while running on edk2 EFI. At rare cases, Qemu errors out with `qemu: WHPX: Unexpected VP exit code 4` +Steps to reproduce: +1. Grab Windows 11 23H2 ISO from https://www.microsoft.com/en-Us/software-download/windows11 using either Media Creation Tool or directly and save it under C:\\windows11_23H2.iso +2. Download QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe and install it into C:\\Program Files\\qemu +3. Make one merged EFI file from two ones bundled in QEMU 9.0 (merged EFI is the only working option for edk2 EFI on windows host): `cd /d C:\Program Files\qemu\share` + +`copy /B edk2-i386-vars.fd + edk2-x86_64-code.fd edk2-x86_64.fd` + +4. Run this command: + +`qemu-system-x86_64.exe -accel whpx -bios share\edk2-x86_64.fd -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -machine q35 -m 4096 -cdrom C:\windows11_23H2.iso` + +5. Press any key once you see "Press any key to boot from CD..." and wait until Windows Setup suggests to opt for language and currency. +6. Click red "X" close button inside Windows Setup and confirm your choice when Windows Setup asks you to. + +Windows Setup sends a reboot signal to the underlying hardware and Qemu freezes. +Additional information: +If `-bios share\edk2-x86_64.fd` switch is omitted, this command works ok: + +`qemu-system-x86_64 -accel whpx -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -machine q35 -m 4096 -cdrom D:\originalWindows11_23H2.iso` + +This bug seems to be closely related to this one: https://gitlab.com/qemu-project/qemu/-/issues/2042 - Not able to reboot Linux guest on Windows host diff --git a/results/classifier/gemma3:12b/hypervisor/2429 b/results/classifier/gemma3:12b/hypervisor/2429 new file mode 100644 index 00000000..e4c8e658 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2429 @@ -0,0 +1,30 @@ + +Enabling SVM in guest forcefully enables hypervisor flag and doesn't respect hv-vendor-id +Description of problem: +When the SVM cpu feature is enabled in a guest; despite both the hypervisor feature being disabled and hv-vendor-id being set to AuthenticAMD, the guest hypervisor is detected as "Microsoft Hv" and the hypervisor flag is present. Whereas when the SVM cpu feature is disabled but everything else is still the same, the vendor-id is detected as "AuthenticAMD" and the hypervisor flag isn't present, which is exactly as it was intended by the parameters. Therefore, from what I can tell, enabling the SVM cpu feature (which is necessary for nested-virtualization on AMD CPUs) renders hypervisor=off and hv-vendor-id useless by forcefully enabling the hypervisor flag and setting the hypervisor's vendor-id to the default "Microsoft Hv", which normally shouldn't happen. +Steps to reproduce: +1. Run a Windows 11 virtual machine with the given CLI arguments including svm=on +2. I'm not sure how to check the hypervisor vendor from Command Prompt or PowerShell in Windows, so I used [Paranoid Fish](https://github.com/a0rtega/pafish) to check the hypervisor vendor, it's a utility for checking various different VM detection flags in a guest. +3. You should see "Hypervisor: Microsoft Hv" +Additional information: +Screenshot of Paranoid Fish with SVM enabled: + +{width="291" height="86"} ("Hypervisor:" is visible, meaning "-hypervisor" was ignored) + +{width="369" height="13"} (traced means the hypervisor bit is present, meaning `hypervisor=off` was ignored) + +And with SVM disabled: + + ("Hypervisor:" isn't visible, as intended) + +{width="339" height="12"} (OK means the hypervisor bit isn't present, as intended) + +# Solution + +I finally found a solution to this. And it looks like the problem might not even have been on QEMU's side from the beginning. First disabling Virtualization Based Security (Memory Integrity) from settings and then running the following command: `bcdedit /set hypervisorlaunchtype off` in an admin PowerShell fixes the issue and now with SVM enabled, regardless of whether Hyper-V is enabled or not, I see the following CPU information in Paranoid Fish (identical to when SVM was disabled and everything is as intended, and I can still see that virtualization is enabled in task manager): + + + + + +It looks like for some odd reason Windows enables the hypervisor bit on the CPU and sets the hypervisor's vendor-id to "Microsoft Hv" when SVM is enabled in the VM. No clue as to why it does that, but disabling Virtualization Based Security (Memory Integrity) and running the command I mentioned earlier in an admin PowerShell fixes the problem regardless. diff --git a/results/classifier/gemma3:12b/hypervisor/2475 b/results/classifier/gemma3:12b/hypervisor/2475 new file mode 100644 index 00000000..807b5aa7 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2475 @@ -0,0 +1,2 @@ + +Inconsistency between cpu_tb_exec() and qemu_plugin_register_vcpu_tb_exec_cb()? diff --git a/results/classifier/gemma3:12b/hypervisor/2480 b/results/classifier/gemma3:12b/hypervisor/2480 new file mode 100644 index 00000000..d4049ddf --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2480 @@ -0,0 +1,30 @@ + +Two questions about VFIO device live migration +Description of problem: +For my own pcie device, i implement system memory && device memory dirty bitmap track and works well + +use pre-copy mode live migration by the way. + +first question: +- for system memory dirty bitmap sync, notice that last sync will come early than i expected + read qemu code and found qemu will call every savevm_state.handlers->save_live_complete_precopy callback + in "qemu_savevm_state_complete_precopy_iterable", and "vfio" handler will always behind "ram". + so here is question, my own vfio device will only be halted after "vfio" handler enter + save_live_complete_precopy, and last system memory dirty bitmap sync will come with "ram"'s + save_live_complete_precopy, there will be some system dirty between this period, should we add one more + system dirty bitmap sync after "vfio"'s save_live_complete_precopy + +second question: +- notice that qemu will clean up migration and call every savevm_state.handlers->save_cleanup call back, and + in this function, qemu will only call vfio listener's log_global_stop call back when vm_is_running + but for my vfio device, state will be paused(postmigrate) when enter here, so there is no chance for qemu + to relese some resource create by my device kernel mode driver, where should i put the logic about "stop + migration resource" anyway + +Thanks ^_^ +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2482 b/results/classifier/gemma3:12b/hypervisor/2482 new file mode 100644 index 00000000..fb427300 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2482 @@ -0,0 +1,137 @@ + +qemu-system-x86_64: Live Migration fails with BLOCK_JOB_ERROR +Description of problem: +After disk migration is completed and RAM migration is being performed, migration status switches to 'pre-switchover'. +In the 'pre-switchover' migration state, block jobs status is still set to 'ready' instead of 'running' +on queried for block job status when 'offset' and 'length' diverged. Thus, It results in BLOCK_JOB_ERROR. +Steps to reproduce: +On source host +1. Add disk(s) that needed to be migrated by issuing 'blockdev-add' QMP command. +2. start blockdev-mirror operations to perform disk(s) transfer by issuing QMP command +3. start RAM migration. (send HMP commands - listed below +4. Migration status changed to 'pre-switchover'. While in 'pre-switchover', check for disk activity + +While RAM migration is happening, Migration status is changed to 'pre-switchover' +and observe that block jobs 'offset' and 'length' diverged. But, block job status is still set to 'ready' instead of 'running'. + +On destination host +1. Launch the VM in listening mode (-incoming) for migrations +2. start NBD server +3. add disks to NBD server. +4. set migration parameters by sending HMP commands +Additional information: +# On SOURCE Host, start all blockdev-add operations +# Issue QMP commands (blockdev-add) for all block devices ("drive-scsi-disk-0" and "drive-scsi-disk-1") of VM + +``` + { + "execute" => "blockdev-add", + "arguments" => { + "driver" => "raw", + "node-name" => "node_drive-scsi-disk-0", + "auto-read-only" => false, + "read-only" => false, + "file" => { + "driver" => "nbd", + "export" => "drive-scsi-disk-0", + "server" => { + "type" => "inet", + "host" => "2600:3c0f:17:14::21", + "port" => "37552", + }, + "tls-creds" => "tlscreds0" + } + } + } +``` + + { + "execute" => "blockdev-add", + "arguments" => { + "driver" => "raw", + "node-name" => "node_drive-scsi-disk-1", + "auto-read-only" => false, + "read-only" => false, + "file" => { + "driver" => "nbd", + "export" => "drive-scsi-disk-1", + "server" => { + "type" => "inet", + "host" => "2600:3c0f:17:14::21", + "port" => "37552", + }, + "tls-creds" => "tlscreds0" + } + } + } + +# On SOURCE Host, start all blockdev-mirror operations to start disk transfer +# i.e Issue QMP commands (blockdev-mirror) for each of those block devices ("drive-scsi-disk-0" and "drive-scsi-disk-1") + +``` + { + "execute" => "blockdev-mirror", + "arguments" => { + "device" => "drive-scsi-disk0", + "target" => "node_drive-scsi-disk-0", + "speed" => 100000000, + "sync" => "full", + } + } +``` + +``` + { + "execute" => "blockdev-mirror", + "arguments" => { + "device" => "drive-scsi-disk1", + "target" => "node_drive-scsi-disk-1", + "speed" => 100000000, + "sync" => "full", + } + } +``` + +# NBD server configuration on destination host by issuing QMP command +# Start NBD server +``` + { + "execute" => "nbd-server-start", + "arguments" => { + "addr" => { + "type" => "inet", + "data" => { + "host" => "2600:3c0f:17:14::21", + "port" => "37552" + } + }, + "tls-creds" => "tlscreds0" + } + } +``` + +# On DESTINATION Host +# Register incoming disks(2) with NBD server by issuing QMP commands to VM on the destination host +# Disk# 1 +``` + { + "execute" => "nbd-server-add", + "arguments" => { + "device" => "drive-scsi-disk0", + "writable" => true + } + } +``` +# Disk# 2 +``` + { + "execute" => "nbd-server-add", + "arguments" => { + "device" => "drive-scsi-disk1", + "writable" => true + } + } +``` + +# Wait for disks to finish the bulk of the data migration. +# diff --git a/results/classifier/gemma3:12b/hypervisor/2505 b/results/classifier/gemma3:12b/hypervisor/2505 new file mode 100644 index 00000000..ca6bd8bb --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2505 @@ -0,0 +1,2 @@ + +Interpreter ELF flags ignored when selecting CPU diff --git a/results/classifier/gemma3:12b/hypervisor/2515 b/results/classifier/gemma3:12b/hypervisor/2515 new file mode 100644 index 00000000..11b003f9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2515 @@ -0,0 +1,47 @@ + +qemu -daemonize crashes on macOS with "NSPlaceholderDate initialize may have been in progress in another thread" +Description of problem: +Context: I build [an open source project](https://tsduck.io/) on several operating systems and architectures. For riscv64, s390x, ppc64, I build in emulated virtual machines. The three emulated OS work correctly when running qemu manually and the project is correctly built. + +Now, I want to automate the process in a script: for each target architecture, boot the VM (start qemu as a background process), connect to the VM using ssh, build the software, collect the binaries, shut down the VM. + +Starting the same qemu command as used interactively as a background process with `&` does not work and fails immediately, apparently because of the lack of stdin. So, I added option `-daemonize` (and removed `-nographic` because an error message says the two options are incompatible). + +Using `-daemonize` instead of `-nographic`, all qemu command immediately fail with the following error: + +``` +objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. +objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. +``` +Steps to reproduce: +``` +$ qemu-system-riscv64 -machine virt -smp 8 -m 8192 -daemonize \ + -bios fw_jump.bin -kernel u-boot.bin \ + -device virtio-net-device,netdev=net \ + -netdev user,id=net,hostfwd=tcp::2233-:22 \ + -drive file=disk.qcow2,format=qcow2,if=virtio -device virtio-rng-pci +objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. +objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. + + +$ qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -daemonize \ + -drive file=disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none \ + -device virtio-blk-ccw,devno=fe.0.0002,drive=drive-virtio-disk0,bootindex=1 \ + -nic user,hostfwd=tcp::2288-:22 +objc[1209]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. +objc[1209]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. + + +$ qemu-system-ppc64 -smp 8 -m 8192 -daemonize \ + -drive file=disk.qcow2,format=qcow2 -nic user,hostfwd=tcp::2299-:22 +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ccf-assist=on +objc[1166]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. +objc[1166]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. +``` + +All the above commands work correctly when using `-nographic` instead of `-daemonize`. The virtual disks are the same as in the interactive runs, with a fully configured Linux OS (Ubuntu or Debian). +Additional information: +From a [report from here](https://stackoverflow.com/questions/63041445/python-os-high-sierra-nsplaceholderdate-error), I tried to define the environment variable `OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES` before running qemu. The `[__NSPlaceholderDate initialize]` errors disappear but qemu still crashes immediately. diff --git a/results/classifier/gemma3:12b/hypervisor/2516 b/results/classifier/gemma3:12b/hypervisor/2516 new file mode 100644 index 00000000..438784be --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2516 @@ -0,0 +1,2 @@ + +Qemu 9.1 dropped support for Ubuntu 20.04 diff --git a/results/classifier/gemma3:12b/hypervisor/2517 b/results/classifier/gemma3:12b/hypervisor/2517 new file mode 100644 index 00000000..0defd7e8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2517 @@ -0,0 +1,2 @@ + +destroying a vCPU will leak its AddressSpaces diff --git a/results/classifier/gemma3:12b/hypervisor/2522 b/results/classifier/gemma3:12b/hypervisor/2522 new file mode 100644 index 00000000..f39e1238 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2522 @@ -0,0 +1,18 @@ + +[9.0.2] PPC: incorrect name filed in vmstate_tlbemb_entry, broken snapshot replay +Description of problem: +Fix commit: a90db15 +When using the Record/replay feature on ppc emulation (qemu-system-ppc binary), an error occurred during loading: +``` +qemu-system-ppc: Missing section footer for cpu +qemu-system-ppc: Error -22 while loading VM state +qemu-system-ppc: Could not load snapshot for icount replay +``` +I found a typo that led to this error + +more info in https://lists.nongnu.org/archive/html/qemu-devel/2024-08/msg02951.html +Steps to reproduce: +1. Run bare metal example from the attachment with the first command-line to create snapshot. +2. Run bare metal example from the attachment with the second command-line to replay snapshot. +Additional information: +Use this example [ppc-e500.zip](/uploads/04e47528c74ed9a564c212a17c480a1d/ppc-e500.zip) diff --git a/results/classifier/gemma3:12b/hypervisor/2528 b/results/classifier/gemma3:12b/hypervisor/2528 new file mode 100644 index 00000000..55f598b6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2528 @@ -0,0 +1,10 @@ + +nbd: CVE-2024-7409 fix is incomplete +Description of problem: +Patch will hit list soon, but opening issue here since if this misses 9.1, we would need to allocate a second CVE for having an incomplete fix (a remaining use-after-free) in the code originally proposed for CVE-2024-7409. +Steps to reproduce: +1. stress test of attempting repeated 'qemu-nbd --list' in parallel with repeated 'nbd-server-start/nbd-server-stop' loops in a qemu process revealed a use-after-free SEGV of nbd_server->listener +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2531 b/results/classifier/gemma3:12b/hypervisor/2531 new file mode 100644 index 00000000..ba2eef47 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2531 @@ -0,0 +1,61 @@ + +QEMU internal SIGSEGV when creating an x86_64 Debian chroot from an aarch64 host. +Description of problem: +When I try to create a x86_64 Debian chroot using debootstrap from an aarch64 host system, QEMU segfaults causing the process to fail. +Steps to reproduce: +1. Run `sudo apt install debootstrap qemu-user-static binfmt-support` +2. Run `sudo debootstrap --arch amd64 bookworm debian_chroot http://deb.debian.org/debian/` +Additional information: +End of deboostrap output: +``` +I: Configuring dash... +I: Configuring libpam-modules:amd64... +I: Configuring grep... +I: Configuring perl-base... +I: Configuring gzip... +I: Configuring passwd... +I: Configuring login... +I: Configuring apt... +I: Configuring adduser... +I: Configuring libc-bin... +W: Failure while configuring required packages. +W: See /home/allen/debian_chroot/debootstrap/debootstrap.log for details (possibly the package passwd is at fault) +``` + +End of debootstrap log: +``` +$ tail /home/allen/debian_chroot/debootstrap/debootstrap.log -n30 +Setting up grep (3.8-5) ... +Setting up perl-base (5.36.0-7+deb12u1) ... +Setting up gzip (1.12-1) ... +Setting up passwd (1:4.13+dfsg1-1+b1) ... +x86_64-binfmt-P: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault +groupadd: group 'shadow' already exists +Group ID 42 has been allocated for the shadow group. You have either +used 42 yourself or created a shadow group with a different ID. +Please correct this problem and reconfigure with dpkg --configure passwd''. + +Note that both user and group IDs in the range 0-99 are globally +allocated by the Debian project and must be the same on every Debian +system. +dpkg: error processing package passwd (--configure): + installed passwd package post-installation script subprocess returned error exit status 1 +Setting up libpam-runtime (1.5.2-6+deb12u1) ... +Setting up login (1:4.13+dfsg1-1+b1) ... +dpkg: apt: dependency problems, but configuring anyway as you requested: + apt depends on adduser. + +Setting up apt (2.6.1) ... +dpkg: adduser: dependency problems, but configuring anyway as you requested: + adduser depends on passwd; however: + Package passwd is not configured yet. + +Setting up adduser (3.134) ... +Processing triggers for libc-bin (2.36-9+deb12u7) ... +Errors were encountered while processing: + passwd +``` + +Full debootstrap log: +[debootstrap.log](/uploads/4eb24abd98a647e08bd03deea897b9dd/debootstrap.log) diff --git a/results/classifier/gemma3:12b/hypervisor/2535 b/results/classifier/gemma3:12b/hypervisor/2535 new file mode 100644 index 00000000..28830059 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2535 @@ -0,0 +1,2 @@ + +Security patch of CVE-2024-4693 backport request diff --git a/results/classifier/gemma3:12b/hypervisor/2545 b/results/classifier/gemma3:12b/hypervisor/2545 new file mode 100644 index 00000000..93a3d805 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2545 @@ -0,0 +1,10 @@ + +QEMU Version 9.0.0 - HAXM 7.8.0.0 - Error : qemu-system-x86_64.exe: -accel hax: invalid accelerator hax +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2556 b/results/classifier/gemma3:12b/hypervisor/2556 new file mode 100644 index 00000000..0d455315 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2556 @@ -0,0 +1,13 @@ + +memory balloon massively slows Windows shutdown (almost feels like it crashed for minutes) +Description of problem: +When reducing the memory using ballooning, the shutdown takes very long. One may even assume it crashed, but it will eventually power off. +Steps to reproduce: +1. wait until Windows has booted +2. reduce the balloon by multiple GB via monitor: `balloon 8192` _(8 GB balloon, memory size is 24 GB)_ +3. Shut down (or reboot) Windows + +The system shows the boot screen at shutdown for a long time. + +It's about 10 seconds extra time per reduced balloon size. So when resizing the balloon from 24 GB to 8 GB, that's 16 GB. +So the shutdown needs: 16 * 10 = 160 seconds = **about 3 minutes** diff --git a/results/classifier/gemma3:12b/hypervisor/2568 b/results/classifier/gemma3:12b/hypervisor/2568 new file mode 100644 index 00000000..052ccdc8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2568 @@ -0,0 +1,2 @@ + +[AARCH64] HPFAR_EL2.NS not set for non secure read in S-EL1 diff --git a/results/classifier/gemma3:12b/hypervisor/2577 b/results/classifier/gemma3:12b/hypervisor/2577 new file mode 100644 index 00000000..2b3dfbfa --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2577 @@ -0,0 +1,2 @@ + +buildx: Illegal instruction, exit code: 132 diff --git a/results/classifier/gemma3:12b/hypervisor/2579 b/results/classifier/gemma3:12b/hypervisor/2579 new file mode 100644 index 00000000..b69fcff5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2579 @@ -0,0 +1,2 @@ + +Is there a plan to fix the vulnerabilities CVE-2023-1386 and CVE-2021-3735? diff --git a/results/classifier/gemma3:12b/hypervisor/2589 b/results/classifier/gemma3:12b/hypervisor/2589 new file mode 100644 index 00000000..988a3cf8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2589 @@ -0,0 +1,57 @@ + +Support guest shutdown of Alpine Linux in guest agent +Description of problem: +The qemu-guest-agent's shutdown calls `/sbin/shutdown` with the apropriate flags to shut down a posix system. On Alpine Linux, which is based on busybox, there is no `/sbin/shutdown`, instead there are `/sbin/poweroff`, `/sbin/halt` and `/sbin/reboot`. We have used a downstream patch for years that will exec those as a fallback in case execing `/sbin/shutdown` fails. + +With qemu 9.2 this patch no longer applies and it is probably time to solve this properly in upstream qemu. + +The question is how? + +Some options: + +- Set the powerdown, halt and reboot commands via build time configure option +- Add a fallback if the `execlp` fails (similar to what downstream Alpine's patch does now). We could for example give `ga_run_command` a `const char **argv[]`, and try `execvp` all of them before erroring out. +- Test the existence of `/sbin/shutdown` before calling `ga_run_command`. +- Do nothing. Let downstream Alpine Linux handle it. +Steps to reproduce: +1. Build qemu-guest-agent for Alpine Linux +2. boot a Alpine linux VM and install the qemu-guest-agent +3. Try shutdown the VM via qmp command. +Additional information: +The patch that we previously used that no longer applies: +```diff +diff --git a/qga/commands-posix.c b/qga/commands-posix.c +index 954efed01..61427652c 100644 +--- a/qga/commands-posix.c ++++ b/qga/commands-posix.c +@@ -84,6 +84,7 @@ static void ga_wait_child(pid_t pid, int *status, Error **errp) + void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp) + { + const char *shutdown_flag; ++ const char *fallback_cmd = NULL; + Error *local_err = NULL; + pid_t pid; + int status; +@@ -101,10 +102,13 @@ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp) + slog("guest-shutdown called, mode: %s", mode); + if (!has_mode || strcmp(mode, "powerdown") == 0) { + shutdown_flag = powerdown_flag; ++ fallback_cmd = "/sbin/poweroff"; + } else if (strcmp(mode, "halt") == 0) { + shutdown_flag = halt_flag; ++ fallback_cmd = "/sbin/halt"; + } else if (strcmp(mode, "reboot") == 0) { + shutdown_flag = reboot_flag; ++ fallback_cmd = "/sbin/reboot"; + } else { + error_setg(errp, + "mode is invalid (valid values are: halt|powerdown|reboot"); +@@ -125,6 +129,7 @@ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp) + #else + execl("/sbin/shutdown", "shutdown", "-h", shutdown_flag, "+0", + "hypervisor initiated shutdown", (char *)NULL); ++ execle(fallback_cmd, fallback_cmd, (char*)NULL, environ); + #endif + _exit(EXIT_FAILURE); + } else if (pid < 0) { +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2597 b/results/classifier/gemma3:12b/hypervisor/2597 new file mode 100644 index 00000000..196b4b92 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2597 @@ -0,0 +1,2 @@ + +qemu-i386 crashes on ppc64el diff --git a/results/classifier/gemma3:12b/hypervisor/2598 b/results/classifier/gemma3:12b/hypervisor/2598 new file mode 100644 index 00000000..f6875487 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2598 @@ -0,0 +1,2 @@ + +linux-user on riscv64 host: Unable to find a guest_base to satisfy all guest address mapping requirements 00000000-ffffffff diff --git a/results/classifier/gemma3:12b/hypervisor/2614 b/results/classifier/gemma3:12b/hypervisor/2614 new file mode 100644 index 00000000..ca303287 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2614 @@ -0,0 +1,2 @@ + +vhost user documentation for VHOST_USER_ADD_MEM_REG incorrect diff --git a/results/classifier/gemma3:12b/hypervisor/264 b/results/classifier/gemma3:12b/hypervisor/264 new file mode 100644 index 00000000..2c3a8933 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/264 @@ -0,0 +1,2 @@ + +qed leaked clusters diff --git a/results/classifier/gemma3:12b/hypervisor/2644 b/results/classifier/gemma3:12b/hypervisor/2644 new file mode 100644 index 00000000..87dd6a4d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2644 @@ -0,0 +1,67 @@ + +openbsd 7.5 crashes with QEMU since "virtio-pci: Add lookup subregion of VirtIOPCIRegion MR" +Description of problem: +Attempt to boot OpenBSD 7.5 in QEMU current git HEAD fdf250e5a37830615e324017cb3a503e84b3712c. + +It immediately aborts with + +``` +Thread 6 (Thread 0x7fe06d2006c0 (LWP 2797401) "CPU 0/KVM"): +#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 +#1 0x00007fe0764476d3 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78 +#2 0x00007fe0763eec4e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#3 0x00007fe0763d6902 in __GI_abort () at abort.c:79 +#4 0x00007fe0763d681e in __assert_fail_base (fmt=0x7fe076562b98 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a00b998b4d "mrs.mr", file=file@entry=0x55a00b998b33 "../hw/virtio/virtio-pci.c", line=line@entry=620, function=function@entry=0x55a00bb596b0 <__PRETTY_FUNCTION__.13> "virtio_address_space_lookup") at assert.c:94 +#5 0x00007fe0763e6d87 in __assert_fail (assertion=assertion@entry=0x55a00b998b4d "mrs.mr", file=file@entry=0x55a00b998b33 "../hw/virtio/virtio-pci.c", line=line@entry=620, function=function@entry=0x55a00bb596b0 <__PRETTY_FUNCTION__.13> "virtio_address_space_lookup") at assert.c:103 +#6 0x000055a00b49d368 in virtio_address_space_lookup (proxy=proxy@entry=0x55a0213a59d0, off=off@entry=0x7fe06d1f3370, len=len@entry=1) at ../hw/virtio/virtio-pci.c:620 +#7 0x000055a00b4a127f in virtio_address_space_write (proxy=0x55a0213a59d0, addr=<optimized out>, buf=0x55a0213b32c8 "", len=1) at ../hw/virtio/virtio-pci.c:654 +#8 virtio_write_config (pci_dev=<optimized out>, address=<optimized out>, val=<optimized out>, len=<optimized out>) at ../hw/virtio/virtio-pci.c:790 +#9 0x000055a00b6edc30 in memory_region_write_accessor (mr=0x55a01fa1b470, addr=4194520, value=<optimized out>, size=1, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../system/memory.c:497 +#10 0x000055a00b6ed4be in access_with_adjusted_size (addr=addr@entry=4194520, value=0x7fe06d1f34c8, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55a00b6edbb0 <memory_region_write_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573 +#11 0x000055a00b6ed7fa in memory_region_dispatch_write (mr=mr@entry=0x55a01fa1b470, addr=addr@entry=4194520, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1560 +#12 0x000055a00b6f593f in flatview_write_continue_step (attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028 "", mr_addr=4194520, l=l@entry=0x7fe06d1f3590, mr=0x55a01fa1b470, len=1) at ../system/physmem.c:2786 +#13 0x000055a00b6f6058 in flatview_write_continue (fv=0x7fdf505079f0, addr=2956984536, attrs=..., ptr=0xb04000d8, len=1, mr_addr=<optimized out>, l=<optimized out>, mr=<optimized out>) at .--Type <RET> for more, q to quit, c to continue without paging-- +./system/physmem.c:2816 +#14 flatview_write (fv=0x7fdf505079f0, addr=addr@entry=2956984536, attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028, len=len@entry=1) at ../system/physmem.c:2847 +#15 0x000055a00b6f97a1 in address_space_write (as=0x55a00ca34600 <address_space_memory>, addr=2956984536, attrs=..., buf=0x7fe07988e028, len=1) at ../system/physmem.c:2967 +#16 address_space_rw (as=0x55a00ca34600 <address_space_memory>, addr=2956984536, attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028, len=1, is_write=<optimized out>) at ../system/physmem.c:2977 +#17 0x000055a00b75c256 in kvm_cpu_exec (cpu=cpu@entry=0x55a01f9cb690) at ../accel/kvm/kvm-all.c:3184 +#18 0x000055a00b75da25 in kvm_vcpu_thread_fn (arg=arg@entry=0x55a01f9cb690) at ../accel/kvm/kvm-accel-ops.c:50 +#19 0x000055a00b94daa8 in qemu_thread_start (args=0x55a01f9d2140) at ../util/qemu-thread-posix.c:541 +#20 0x00007fe0764456d7 in start_thread (arg=<optimized out>) at pthread_create.c:447 +#21 0x00007fe0764c9414 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100 + +``` + +Git bisect points to + +``` +commit ffa8a3e3b2e6ff017113b98d500d6a9e05b1560a (HEAD) +Author: Gao Shiyuan <gaoshiyuan@baidu.com> +Date: Tue Sep 3 20:03:04 2024 +0800 + + virtio-pci: Add lookup subregion of VirtIOPCIRegion MR + + Now virtio_address_space_lookup only lookup common/isr/device/notify + MR and exclude their subregions. + + When VHOST_USER_PROTOCOL_F_HOST_NOTIFIER enable, the notify MR has + host-notifier subregions and we need use host-notifier MR to + notify the hardware accelerator directly instead of eventfd notify. + + Further more, maybe common/isr/device MR also has subregions in + the future, so need memory_region_find for each MR incluing + their subregions. + + Add lookup subregion of VirtIOPCIRegion MR instead of only lookup container MR. + + Fixes: a93c8d8 ("virtio-pci: Replace modern_as with direct access to modern_bar") + Co-developed-by: Zuo Boqun <zuoboqun@baidu.com> + Signed-off-by: Gao Shiyuan <gaoshiyuan@baidu.com> + Signed-off-by: Zuo Boqun <zuoboqun@baidu.com> + Message-Id: <20240903120304.97833-1-gaoshiyuan@baidu.com> + Reviewed-by: Michael S. Tsirkin <mst@redhat.com> + Signed-off-by: Michael S. Tsirkin <mst@redhat.com> +``` + +cc @mstredhat diff --git a/results/classifier/gemma3:12b/hypervisor/2646 b/results/classifier/gemma3:12b/hypervisor/2646 new file mode 100644 index 00000000..7e2dedf2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2646 @@ -0,0 +1,26 @@ + +osx 10.6.8 guest on x86-64 macos 10.12 host can't boot on HVF, boots on tcg +Description of problem: +for some reason HVF acceleration does not work with mac-on-mac. Haiku beta5 (x64), win10 x64, Debian netinstall 12.7.0 - all works. +Steps to reproduce: +``` +1. get 10.6.8 image from archive.org +2. bin/qemu-system-x86_64 -device isa-applesmc,osk="well_known_string" -usb -M pc-q35-2.11 -device usb-kbd -device usb-tablet -m 1536 -smp 1 -cpu Penryn,vendor=GenuineIntel,+ssse3,+sse4.1,+sse4.2 -L /opt/local/share/qemu -device ac97 -vnc :3 --no-reboot -accel hvf -boot c -bios usr/share/edk2-ovmf-x64/OVMF_CODE.fd -hda osx-10.6-xcode-compressed-efi.qcow2 -d unimp +audio: Could not create a backend for voice `ac97.pi' +audio: Could not create a backend for voice `ac97.mc' +audio: Could not create a backend for voice `ac97.pi' +audio: Could not create a backend for voice `ac97.mc' +ahci: IRQ#0 level:1 +ahci: IRQ#0 level:1 + +{many more of those} +``` +and at this point qemu quits. + +without --no-reboot it reboots + +tried both UEFI boot (using https://github.com/khronokernel/khronokernel.github.io/blob/master/Binaries/OpenCore/EFI-LEGACY.img.zip?raw=true , currently integrated into hdd image) and Clover-5160-X64.iso + +if I remove -accel hvf and replace it with accel tcg guest boots. + +i tried to capture moment when it reboots on video but I can't catch anything :( diff --git a/results/classifier/gemma3:12b/hypervisor/2656 b/results/classifier/gemma3:12b/hypervisor/2656 new file mode 100644 index 00000000..df9a94cf --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2656 @@ -0,0 +1,2 @@ + +impossible to specify pauth-impdef=on when specifying multiple accelerators diff --git a/results/classifier/gemma3:12b/hypervisor/2659 b/results/classifier/gemma3:12b/hypervisor/2659 new file mode 100644 index 00000000..60e6b4e1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2659 @@ -0,0 +1,2 @@ + +msys2-64bit test-aio intermittent CI failure with "test_timer_schedule: assertion failed: (aio_poll(ctx, true)) FAIL" diff --git a/results/classifier/gemma3:12b/hypervisor/266 b/results/classifier/gemma3:12b/hypervisor/266 new file mode 100644 index 00000000..96c43e11 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/266 @@ -0,0 +1,2 @@ + +'mtfsf' instruction can clear FI incorrectly diff --git a/results/classifier/gemma3:12b/hypervisor/2665 b/results/classifier/gemma3:12b/hypervisor/2665 new file mode 100644 index 00000000..e1525e1b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2665 @@ -0,0 +1,12 @@ + +target/arm: cannot boot when CPU supports SME +Description of problem: +On macOS 15.2 beta, Apple's Hypervisor.framework exposes the SME feat flag to QEMU. As a result, in `arm_cpu_sme_finalize`, `cpu_isar_feature(aa64_sme, cpu)` returns true and the program will always exit with the following: + +``` +qemu-aarch64-softmmu: cannot disable sme4224 +All SME vector lengths are disabled. +With SME enabled, at least one vector length must be enabled. +``` + +This is because `vq_supported` and `vq_init` are both 0 as they are not initialized anywhere. It seems that in the original commit e74c097638d38b46d9c68f11565432034afc0ad0 the only place `cpu->sme_vq.supported` is initialized is with `aarch64_max_initfn` when KVM and HVF are not used as the backend. diff --git a/results/classifier/gemma3:12b/hypervisor/2669 b/results/classifier/gemma3:12b/hypervisor/2669 new file mode 100644 index 00000000..1957c747 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2669 @@ -0,0 +1,19 @@ + +CPU Hotplug (Host Model) Causes the Windows VM to BSOD +Description of problem: +The QEMU runs on a host with the Intel(R) Xeon(R) CPU E3-1230 v6 CPU which supports Software Guard Extension (SGX). I start a VM with Windows Server 2019 inside and with `-cpu host,...`. When I attempts to hotplug additional CPU (when the VM is running), the OS issues a bug check 0x3e (`MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED`). The problem is that the newly hotplugged CPU is not evaluated as "equivalent enough" compared to the already present CPUs. I did some more digging and reverse engineering and it looks like the CPU being hotplugged has SGX turned off. This seems to be fixed when the VM reboots. + +I tried to disable SGX through `-cpu host,-sgx` which helps (the VM successfully accepts the hotplugged CPU), however, `+sgx` does not help (seems to have no effect on the CPU being hotplugged). + +My goal is to be able to hotplug CPUs even when the host CPU supports SGX. + +I tested with QEMU 8.0.0, 9.1.0, 9.1.1 and 9.1.50 (current master) but with no luck. +Steps to reproduce: +1. Create a simple Windows VM, +2. start the VM, +3. use `qpm-shell` to hotplug a CPU (https://www.qemu.org/docs/master/system/cpu-hotplug.html). + +I can provide you the VM as well but its image (QCOW2) has around 10G in size. + +Best regards +Martin Dráb diff --git a/results/classifier/gemma3:12b/hypervisor/2685 b/results/classifier/gemma3:12b/hypervisor/2685 new file mode 100644 index 00000000..877b95f6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2685 @@ -0,0 +1,2 @@ + +Netbsd 10.0 AMD64 as host fails in tcg? diff --git a/results/classifier/gemma3:12b/hypervisor/2693 b/results/classifier/gemma3:12b/hypervisor/2693 new file mode 100644 index 00000000..4110754d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2693 @@ -0,0 +1,7 @@ + +hv-balloon Migration +Description of problem: +since QEMU version 8.2, the hv-balloon feature has been officially merged, but migration is still not supported. +Are there any planned enhancements to the hv-balloon migration in the near future? +Steps to reproduce: + diff --git a/results/classifier/gemma3:12b/hypervisor/2698 b/results/classifier/gemma3:12b/hypervisor/2698 new file mode 100644 index 00000000..923c2095 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2698 @@ -0,0 +1,10 @@ + +virtualization not working with TCG mode on macOS +Description of problem: +TCG is supposed to work with virtualization=on option but it stops without priting anything. +if I set it to off, I can get to the prompt. +Steps to reproduce: +1. Execute the qemu +2. Hung. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2704 b/results/classifier/gemma3:12b/hypervisor/2704 new file mode 100644 index 00000000..5dde638c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2704 @@ -0,0 +1,303 @@ + +Error when migrating s390x VM from QEMU 9.0 to 9.1: Unknown savevm section or instance 's390_css' +Description of problem: +I have been working on merging QEMU 9.1.1 (directly from Debian unstable), and I'm seeing this problem when trying to migrate an s390x VM from an Oracular host (which runs QEMU 9.0.2) to a Plucky host (which runs QEMU 9.1.1). + +The problem only happens on s390x (host and guest), and only when attempting to migrate from Oracular to Plucky. Migrations between Oracular guests work fine, as well as migrations between Plucky guests. + +This is the error I see after invoking `virsh migrate`: + +``` +error: internal error: QEMU unexpectedly closed the monitor (vm='kvmguest-jammy-normal'): +2024-11-27T21:13:43.745625Z qemu-system-s390x: Unknown savevm section or instance 's390_css' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices +2024-11-27T21:13:43.746914Z qemu-system-s390x: load of migration failed: Invalid argument +``` +Steps to reproduce: +I only have one s390x machine available, so I am resorting to creating two LXD containers that are KVM-capable. One of the containers runs Oracular, the other runs Plucky. Please let me know if you would instructions on how to create such containers. + +Inside the Oracular container, using `uvt-kvm` to simplify the process of creating the VM: + +``` +# uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=s390x label=daily release=oracular +# cat > guesttemplate.xml << _EOF_ +<domain type='kvm'> + <os> + <type>hvm</type> + <boot dev='hd'/> + </os> + <devices> + <interface type='network'> + <source network='default'/> + <model type='virtio'/> + </interface> + <console type='pty' tty='/dev/pts/3'> + <source path='/dev/pts/3'/> + <target type='sclp' port='0'/> + <alias name='console0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + </channel> + </devices> +</domain> +_EOF_ +# uvt-kvm create --template /root/guesttemplate.xml --machine-type s390-ccw-virtio-9.0 --password=ubuntu --ssh-public-key-file /home/ubuntu/.ssh/authorized_keys kvmguest-oracular-upstream-cpu release=oracular arch=s390x label=daily +``` + +Wait a moment for the VM to boot, use `virsh list` to make sure it's running. Note that we force the machine type to be `s390-ccw-virtio-9.0`; this is necessary because Ubuntu overrides the default machine type with its own definition, and we want to make sure to use upstream's type here. + +Make sure you're running QEMU 9.1.1 at least on the Plucky container. Plucky currently ships with QEMU 9.0.2, which doesn't have the problem. If needed, my QEMU 9.1.1 build can be found at https://launchpad.net/~sergiodj/+archive/ubuntu/qemu. + +After everything is in place, try to migrate the machine: + +``` +# virsh migrate --unsafe --live kvmguest-oracular-upstream-cpu qemu+ssh://plucky-container-IP-here/system +error: internal error: QEMU unexpectedly closed the monitor (vm='kvmguest-oracular-upstream-cpu'): 2024-11-29T22:28:21.417201Z qemu-system-s390x: Unknown savevm section or instance 's390_css' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices +2024-11-29T22:28:21.417496Z qemu-system-s390x: load of migration failed: Invalid argument +``` +Additional information: +libvirt log from Oracular (QEMU 9.0.2): + +``` +LC_ALL=C \ [2/1817] +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin \ +USER=root \ +HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/.config \ +/usr/bin/qemu-system-s390x \ +-name guest=kvmguest-oracular-upstream-cpu,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/master-key.aes"}' \ +-machine s390-ccw-virtio-9.0,usb=off,dump-guest-core=off,memory-backend=s390.ram \ +-accel kvm \ +-cpu z13.2-base,aen=on,aefsi=on,diag318=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,cei=on,ap=on,gpereh=on,esop=on,ib=on,siif=on,ibs=on,apqi=on,apft=on,els=on,sief2=on,apqci=on,cte=on,ais=on,bpb=on,64bscao=on,ctop=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on,gsls=on \ +-m size=524288k \ +-object '{"qom-type":"memory-backend-ram","id":"s390.ram","size":536870912}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid fa8bcf1a-8982-47ab-9766-ebbb695008e3 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=38,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device '{"driver":"virtio-serial-ccw","id":"virtio-serial0","devno":"fe.0.0003"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjQuMTA6czM5MHggMjAyNDExMjY=","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":true,"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu.qcow","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"}' \ +-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0000","drive":"libvirt-2-format","id":"virtio-disk0","bootindex":1}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu-ds.qcow","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0001","drive":"libvirt-1-format","id":"virtio-disk1"}' \ +-netdev '{"type":"tap","fd":"39","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-ccw","netdev":"hostnet0","id":"net0","mac":"52:54:00:d8:f0:5c","devno":"fe.0.0002"}' \ +-chardev socket,id=charchannel0,fd=36,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev pty,id=charconsole0 \ +-device '{"driver":"sclpconsole","chardev":"charconsole0","id":"console0"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-device '{"driver":"virtio-balloon-ccw","id":"balloon0","devno":"fe.0.0004"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/3 (label charconsole0) +2024-11-28 20:56:00.522+0000: initiating migration +2024-11-28T20:56:01.114894Z qemu-system-s390x: Sibling indicated error 1 +warning: old compression is deprecated; use multifd compression methods instead +warning: old compression is deprecated; use multifd compression methods instead +warning: old compression is deprecated; use multifd compression methods instead +warning: block migration is deprecated; use blockdev-mirror with NBD instead +``` + +libvirt log from Plucky (QEMU 9.1.1): + +``` +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin \ +USER=root \ +HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/.config \ +/usr/bin/qemu-system-s390x \ +-name guest=kvmguest-oracular-upstream-cpu,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/master-key.aes"}' \ +-machine s390-ccw-virtio-9.0,usb=off,dump-guest-core=off,memory-backend=s390.ram \ +-accel kvm \ +-cpu z13.2-base,aen=on,aefsi=on,diag318=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,cei=on,ap=on,gpereh=on,esop=on,ib=on,siif=on,ibs=on,apqi=on,apft=on,els=on,sief2=on,apqci=on,cte=on,ais=on,bpb=on,64bscao=on,ctop=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on,gsls=on \ +-m size=524288k \ +-object '{"qom-type":"memory-backend-ram","id":"s390.ram","size":536870912}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid fa8bcf1a-8982-47ab-9766-ebbb695008e3 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=35,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device '{"driver":"virtio-serial-ccw","id":"virtio-serial0","devno":"fe.0.0003"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjQuMTA6czM5MHggMjAyNDExMjY=","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":true,"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu.qcow","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"}' \ +-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0000","drive":"libvirt-2-format","id":"virtio-disk0","bootindex":1}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu-ds.qcow","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0001","drive":"libvirt-1-format","id":"virtio-disk1"}' \ +-netdev '{"type":"tap","fd":"36","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-ccw","netdev":"hostnet0","id":"net0","mac":"52:54:00:d8:f0:5c","devno":"fe.0.0002"}' \ +-chardev socket,id=charchannel0,fd=34,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev pty,id=charconsole0 \ +-device '{"driver":"sclpconsole","chardev":"charconsole0","id":"console0"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-incoming defer \ +-device '{"driver":"virtio-balloon-ccw","id":"balloon0","devno":"fe.0.0004"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/3 (label charconsole0) +2024-11-29T22:28:21.417201Z qemu-system-s390x: Unknown savevm section or instance 's390_css' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices +2024-11-29T22:28:21.417496Z qemu-system-s390x: load of migration failed: Invalid argument +``` + +Domain XML: + +```xml +<domain type='kvm' id='3'> + <name>kvmguest-oracular-upstream-cpu</name> + <uuid>fa8bcf1a-8982-47ab-9766-ebbb695008e3</uuid> + <metadata> + <uvt:ssh_known_hosts xmlns:uvt="https://launchpad.net/uvtool/libvirt/1">ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDhWPh2Wfm2Ouh/W+H9IXJGFHfH4UVCB6+EBI0PwuDXR2Ocl4hTTSNPSX2LVS4MfVn9pgl5BK9MUVsMPfFjhmEhpNNt+rmaCelrDT8A7v/RoBY4IGEBFMhAkiwlI7pk3BrFoHEKtiijNLEWczdjMigZvhTs2amn8cUotFIsQSTpM7+7IX+m7clxfe6p59mVPjfMzBhwDG0GyV7CXdMpvsGlE2mPSacWWZ/baWIoFjKcmyQtTjSQleH1qSthI8rD5F7EyYd1Oa8Bo7vZ9j1/DPeGQRJPkebO81hPjm/1x1H5pTITIzARdNuBkM0yuDyqMQLP/u65WGinvXJYm20gEvMbiHGaT3il1QKKNEGmNGtY/SedRE8XQ58n090IBLz/3WJtjgQCY/SRgHUv7nMYYenmshvBfdue9kExJTjwWTRtT2R2UdkxS5UVye4vvDAY0DFuqX13wyvIeCU28MU+HpmnE31m9uXlVXXZxDuqGUBJ1PrDc4a40bvj9yTZTn9NEOs= root@localhost +ssh-dss AAAAB3NzaC1kc3MAAACBAKqzgDKUGk6P/h6N5X4nJoHPr+MQzzXkotN8XEihvtWwvV1KYK+ioT69nA7ThEAZ6rPEjWPt7X4Sy6BcNd4j3kzlaXYLkrMJm3nohqbqQBDxCv8bhozy6HS/VDu95vrpnNFSiMRCfbBye0zyKfZsuRaPaKfHQ+8MnsBqSPxKajFrAAAAFQDuG3ZoanC+oZwMRYZ/am0vhfD+EwAAAIEAixSzoZr03kYZE+LcusyrasvZIqKF3P4M2vtzvFBPpPccFB5XoaqhWI4PvSxGYxZxlj9vRmSc8Yv56jdn8oDPIhFfgZVbDIkvpB2jQdb5VaRVWj7XwUcHB7B117Dr9qA6+6HJtBLRTDdTXzMQ+NhdFp42XCF+1qRefH9VPL9FoxwAAACAJa+u/YvaiGwT0DXBtTz4PgyFYmNHPvXBOVhDAw0likajBiuOdn8oL4KuWTafCq5ReDxXFaMML0OuT86+lSVt2naX0idyHjuSPkgmatozlpcz0kWYhuBl1B1sa3kr8xjDOUJlxkybqpdGJ5aoW+kRO+bpJLEzuXtu6Xshw5fOBZw= root@localhost +ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHI8u/wAvZLJqIpAd5YSpu9VEaRQOxy0FKzyryeb3kjahkryKPhSX65miZ9Lx7oz5nORFsdeS2xR56ZQj+8HpqM= root@localhost +ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDXY+MW1SikusLdkhPrni76LlaZB042p/DVItVeHRCCa root@localhost +</uvt:ssh_known_hosts> + </metadata> + <memory unit='KiB'>524288</memory> + <currentMemory unit='KiB'>524288</currentMemory> + <vcpu placement='static'>1</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='s390x' machine='s390-ccw-virtio-9.0'>hvm</type> + <boot dev='hd'/> + </os> + <cpu mode='custom' match='exact' check='partial'> + <model fallback='forbid'>z13.2-base</model> + <feature policy='require' name='aen'/> + <feature policy='require' name='aefsi'/> + <feature policy='require' name='diag318'/> + <feature policy='require' name='msa5'/> + <feature policy='require' name='msa4'/> + <feature policy='require' name='msa3'/> + <feature policy='require' name='msa2'/> + <feature policy='require' name='msa1'/> + <feature policy='require' name='sthyi'/> + <feature policy='require' name='edat'/> + <feature policy='require' name='ri'/> + <feature policy='require' name='edat2'/> + <feature policy='require' name='vx'/> + <feature policy='require' name='ipter'/> + <feature policy='require' name='cei'/> + <feature policy='require' name='ap'/> + <feature policy='require' name='gpereh'/> + <feature policy='require' name='esop'/> + <feature policy='require' name='ib'/> + <feature policy='require' name='siif'/> + <feature policy='require' name='ibs'/> + <feature policy='require' name='apqi'/> + <feature policy='require' name='apft'/> + <feature policy='require' name='els'/> + <feature policy='require' name='sief2'/> + <feature policy='require' name='apqci'/> + <feature policy='require' name='cte'/> + <feature policy='require' name='ais'/> + <feature policy='require' name='bpb'/> + <feature policy='require' name='64bscao'/> + <feature policy='require' name='ctop'/> + <feature policy='require' name='ppa15'/> + <feature policy='require' name='zpci'/> + <feature policy='require' name='sea_esop2'/> + <feature policy='require' name='te'/> + <feature policy='require' name='cmm'/> + <feature policy='require' name='gsls'/> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-s390x</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu.qcow' index='2'/> + <backingStore type='file' index='3'> + <format type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjQuMTA6czM5MHggMjAyNDExMjY='/> + <backingStore/> + </backingStore> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu-ds.qcow' index='1'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='virtio-disk1'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/> + </disk> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0003'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d8:f0:5c'/> + <source network='default' portid='8b9c05f0-9534-4e05-afff-ec73e4a55b9c' bridge='virbr0'/> + <target dev='vnet1'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0002'/> + </interface> + <console type='pty' tty='/dev/pts/3'> + <source path='/dev/pts/3'/> + <target type='sclp' port='0'/> + <alias name='console0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/run/libvirt/qemu/channel/3-kvmguest-oracular-up/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <audio id='1' type='none'/> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0004'/> + </memballoon> + <panic model='s390'/> + </devices> + <seclabel type='dynamic' model='apparmor' relabel='yes'> + <label>libvirt-fa8bcf1a-8982-47ab-9766-ebbb695008e3</label> + <imagelabel>libvirt-fa8bcf1a-8982-47ab-9766-ebbb695008e3</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+64055:+993</label> + <imagelabel>+64055:+993</imagelabel> + </seclabel> +</domain> +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2713 b/results/classifier/gemma3:12b/hypervisor/2713 new file mode 100644 index 00000000..7f2456cd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2713 @@ -0,0 +1,14 @@ + +Addressing Limitations with 64GB RAM on virt-9.2 Machine Type in QEMU 9.1.93 +Description of problem: +When attempting to run a VM with 64GB of RAM using the `virt-9.2` machine type, QEMU encounters an error related to addressing limitations. It appears that the memory configuration exceeds the 32-bit addressing limit. + +Error output: +**qemu-system-aarch64: Addressing limited to 32 bits, but memory exceeds it by 65498251264 bytes** +Steps to reproduce: +1. Build QEMU from source on macOS (M2 MacBook, arm64). +2. Run the command with the `virt-9.2` machine type and 64GB of RAM. +Additional information: +- Changes in [UTM app](https://github.com/utmapp/UTM/releases) for release v4.6.2 - (macOS) Support > 32GiB RAM configurations in QEMU ([#5537](https://github.com/utmapp/UTM/issues/5537)) +- Although the site advertises release of qemu-9.2.0-rc3, the brew install doesn't install the latest version yet. +- The QEMU build environment includes dependencies installed via Homebrew: libffi, gettext, glib, pkg-config, pixman, ninja, meson, sdl2, gtk+3, gnu-tar. diff --git a/results/classifier/gemma3:12b/hypervisor/2715 b/results/classifier/gemma3:12b/hypervisor/2715 new file mode 100644 index 00000000..ad4f15ff --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2715 @@ -0,0 +1,2 @@ + +QEMU AARCH64 only supports canonical addresses running on x64. diff --git a/results/classifier/gemma3:12b/hypervisor/2725 b/results/classifier/gemma3:12b/hypervisor/2725 new file mode 100644 index 00000000..7f8d724c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2725 @@ -0,0 +1,2 @@ + +multi-arch build at AMD64 for ARM64 fails without flag "F" diff --git a/results/classifier/gemma3:12b/hypervisor/2731 b/results/classifier/gemma3:12b/hypervisor/2731 new file mode 100644 index 00000000..7a562ce8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2731 @@ -0,0 +1,345 @@ + +test_kvm_xen_guest_novector_noapic sometimes fails +Description of problem: +The test_kvm_xen_guest_novector_noapic test of tests/avocado/kvm_xen_guest.py (soon to be moved to tests/functional/test_x86_64_kvm_xen.py ) is sometimes (maybe 1 time out of 50) failing to boot to the shell prompt. The messages on the serial console are: + +``` +Linux version 6.3.0-rc3-00031-g1e760fa3596e (alex@zen) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #21 SMP PREEMPT_DYNAMIC Fri Mar 24 15:04:37 GMT 2023 +Command line: printk.time=0 root=/dev/xvda console=ttyS0 xen_emul_unplug=ide-disks xen_no_vector_callback noapic +x86/fpu: x87 FPU will use FXSAVE +signal: max sigframe size: 1440 +BIOS-provided physical RAM map: +BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +BIOS-e820: [mem 0x0000000000100000-0x0000000007fdffff] usable +BIOS-e820: [mem 0x0000000007fe0000-0x0000000007ffffff] reserved +BIOS-e820: [mem 0x00000000feff8000-0x00000000feffffff] reserved +BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +NX (Execute Disable) protection: active +SMBIOS 2.8 present. +DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 +Hypervisor detected: Xen HVM +Xen version 4.10. +last_pfn = 0x7fe0 max_arch_pfn = 0x400000000 +x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +found SMP MP-table at [mem 0x000f5470-0x000f547f] +ACPI: Early table checksum verification disabled +ACPI: RSDP 0x00000000000F5290 000014 (v00 BOCHS ) +ACPI: RSDT 0x0000000007FE237F 000034 (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: FACP 0x0000000007FE222B 000074 (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: DSDT 0x0000000007FE0040 0021EB (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: FACS 0x0000000007FE0000 000040 +ACPI: APIC 0x0000000007FE229F 000080 (v03 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: HPET 0x0000000007FE231F 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: WAET 0x0000000007FE2357 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: Reserving FACP table memory at [mem 0x7fe222b-0x7fe229e] +ACPI: Reserving DSDT table memory at [mem 0x7fe0040-0x7fe222a] +ACPI: Reserving FACS table memory at [mem 0x7fe0000-0x7fe003f] +ACPI: Reserving APIC table memory at [mem 0x7fe229f-0x7fe231e] +ACPI: Reserving HPET table memory at [mem 0x7fe231f-0x7fe2356] +ACPI: Reserving WAET table memory at [mem 0x7fe2357-0x7fe237e] +Zone ranges: + DMA [mem 0x0000000000001000-0x0000000000ffffff] + DMA32 [mem 0x0000000001000000-0x0000000007fdffff] + Normal empty + Device empty +Movable zone start for each node +Early memory node ranges + node 0: [mem 0x0000000000001000-0x000000000009efff] + node 0: [mem 0x0000000000100000-0x0000000007fdffff] +Initmem setup node 0 [mem 0x0000000000001000-0x0000000007fdffff] +On node 0, zone DMA: 1 pages in unavailable ranges +On node 0, zone DMA: 97 pages in unavailable ranges +On node 0, zone DMA32: 32 pages in unavailable ranges +ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +ACPI: Skipping IOAPIC probe due to 'noapic' option. +ACPI: Using ACPI for processor (LAPIC) configuration information +ACPI: HPET id: 0x8086a201 base: 0xfed00000 +Intel MultiProcessor Specification v1.4 +MPTABLE: OEM ID: BOCHSCPU +MPTABLE: Product ID: 0.1 +MPTABLE: APIC at: 0xFEE00000 +IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 +Processors: 2 +smpboot: Allowing 2 CPUs, 0 hotplug CPUs +[mem 0x08000000-0xfeff7fff] available for PCI devices +Booting paravirtualized kernel on Xen HVM +clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns +setup_percpu: NR_CPUS:64 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 +percpu: Embedded 44 pages/cpu s149304 r0 d30920 u1048576 +Built 1 zonelists, mobility grouping on. Total pages: 31968 +Kernel command line: printk.time=0 root=/dev/xvda console=ttyS0 xen_emul_unplug=ide-disks xen_no_vector_callback noapic +Dentry cache hash table entries: 16384 (order: 5, 131072 bytes, linear) +Inode-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) +mem auto-init: stack:off, heap alloc:off, heap free:off +Memory: 102364K/130552K available (12288K kernel code, 1699K rwdata, 3004K rodata, 1040K init, 2632K bss, 27928K reserved, 0K cma-reserved) +SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 +Dynamic Preempt: full +rcu: Preemptible hierarchical RCU implementation. +rcu: RCU event tracing is enabled. +rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=2. +rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies. +rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 +NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16 +xen:events: Using 2-level ABI +rcu: srcu_init: Setting srcu_struct sizes based on contention. +Console: colour *CGA 80x25 +Cannot get hvm parameter CONSOLE_EVTCHN (18): -22! +printk: console [ttyS0] enabled +ACPI: Core revision 20221020 +ACPI: setting ELCR to 0200 (from 0c00) +clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +APIC: Switch to symmetric I/O mode setup +Not enabling interrupt remapping due to skipped IO-APIC setup +tsc: Unable to calibrate against PIT +tsc: using HPET reference calibration +tsc: Detected 2496.010 MHz processor +clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x23fa80a809f, max_idle_ns: 440795273818 ns +Calibrating delay loop (skipped), value calculated using timer frequency.. 4992.02 BogoMIPS (lpj=2496010) +pid_max: default: 32768 minimum: 301 +LSM: initializing lsm=capability,yama,integrity,selinux +Yama: becoming mindful. +SELinux: Initializing. +Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear) +Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear) +Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0 +Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 +Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +Spectre V2 : Kernel not compiled with retpoline; no mitigation available! +Spectre V2 : Vulnerable +Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +Speculative Store Bypass: Vulnerable +MDS: Vulnerable: Clear CPU buffers attempted, no microcode +MMIO Stale Data: Unknown: No mitigations +Freeing SMP alternatives memory: 24K +APIC timer disabled due to verification failure +smpboot: CPU0: Intel QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1) +Performance Events: unsupported Netburst CPU model 107 no PMU driver, software events only. +rcu: Hierarchical SRCU implementation. +rcu: Max phase no-delay instances is 400. +NMI watchdog: Perf NMI watchdog permanently disabled +smp: Bringing up secondary CPUs ... +x86: Booting SMP configuration: +.... node #0, CPUs: #1 +smp: Brought up 1 node, 2 CPUs +smpboot: Max logical packages: 1 +smpboot: Total of 2 processors activated (9984.04 BogoMIPS) +devtmpfs: initialized +x86/mm: Memory block size: 128MB +clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns +futex hash table entries: 512 (order: 3, 32768 bytes, linear) +PM: RTC time: 12:02:16, date: 2024-12-19 +NET: Registered PF_NETLINK/PF_ROUTE protocol family +audit: initializing netlink subsys (disabled) +audit: type=2000 audit(1734609736.239:1): state=initialized audit_enabled=0 res=1 +thermal_sys: Registered thermal governor 'step_wise' +thermal_sys: Registered thermal governor 'user_space' +cpuidle: using governor ladder +cpuidle: using governor menu +PCI: Using configuration type 1 for base access +HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages +HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page +cryptd: max_cpu_qlen set to 1000 +ACPI: Added _OSI(Module Device) +ACPI: Added _OSI(Processor Device) +ACPI: Added _OSI(3.0 _SCP Extensions) +ACPI: Added _OSI(Processor Aggregator Device) +ACPI: 1 ACPI AML tables successfully acquired and loaded +ACPI: Interpreter enabled +ACPI: PM: (supports S0 S3 S5) +ACPI: Using PIC for interrupt routing +PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +PCI: Using E820 reservations for host bridge windows +ACPI: Enabled 2 GPEs in block 00 to 0F +ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI HPX-Type3] +acpi PNP0A03:00: PCIe port services disabled; not requesting _OSC control +acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended configuration space under this bridge +PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +pci_bus 0000:00: root bus resource [mem 0x08000000-0xfebfffff window] +pci_bus 0000:00: root bus resource [mem 0x100000000-0x17fffffff window] +pci_bus 0000:00: root bus resource [bus 00-ff] +pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 +pci 0000:00:01.0: [8086:7000] type 00 class 0x060100 +pci 0000:00:01.1: [8086:7010] type 00 class 0x010180 +pci 0000:00:01.1: reg 0x20: [io 0xc120-0xc12f] +pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7] +pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io 0x03f6] +pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177] +pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io 0x0376] +pci 0000:00:01.3: [8086:7113] type 00 class 0x068000 +pci 0000:00:01.3: quirk: [io 0x0600-0x063f] claimed by PIIX4 ACPI +pci 0000:00:01.3: quirk: [io 0x0700-0x070f] claimed by PIIX4 SMB +pci 0000:00:02.0: [5853:0001] type 00 class 0xff8000 +pci 0000:00:02.0: reg 0x10: [io 0xc000-0xc0ff] +pci 0000:00:02.0: reg 0x14: [mem 0xfd000000-0xfdffffff pref] +pci 0000:00:03.0: [1af4:1000] type 00 class 0x020000 +pci 0000:00:03.0: reg 0x10: [io 0xc100-0xc11f] +pci 0000:00:03.0: reg 0x14: [mem 0xfebc0000-0xfebc0fff] +pci 0000:00:03.0: reg 0x20: [mem 0xfe000000-0xfe003fff 64bit pref] +pci 0000:00:03.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref] +ACPI: PCI: Interrupt link LNKA configured for IRQ 10 +ACPI: PCI: Interrupt link LNKB configured for IRQ 10 +ACPI: PCI: Interrupt link LNKC configured for IRQ 11 +ACPI: PCI: Interrupt link LNKD configured for IRQ 11 +ACPI: PCI: Interrupt link LNKS configured for IRQ 9 +xen:balloon: Initialising balloon driver +iommu: Default domain type: Translated +iommu: DMA domain TLB invalidation policy: lazy mode +SCSI subsystem initialized +ACPI: bus type USB registered +usbcore: registered new interface driver usbfs +usbcore: registered new interface driver hub +usbcore: registered new device driver usb +pps_core: LinuxPPS API ver. 1 registered +pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +PTP clock support registered +Advanced Linux Sound Architecture Driver Initialized. +PCI: Using ACPI for IRQ routing +hpet: 3 channels of 0 reserved for per-cpu timers +clocksource: Switched to clocksource tsc-early +FS-Cache: Loaded +pnp: PnP ACPI init +pnp: PnP ACPI: found 6 devices +NET: Registered PF_INET protocol family +IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) +tcp_listen_portaddr_hash hash table entries: 128 (order: 0, 4096 bytes, linear) +Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) +TCP established hash table entries: 1024 (order: 1, 8192 bytes, linear) +TCP bind hash table entries: 1024 (order: 4, 65536 bytes, linear) +TCP: Hash tables configured (established 1024 bind 1024) +UDP hash table entries: 256 (order: 2, 24576 bytes, linear) +UDP-Lite hash table entries: 256 (order: 2, 24576 bytes, linear) +NET: Registered PF_UNIX/PF_LOCAL protocol family +RPC: Registered named UNIX socket transport module. +RPC: Registered udp transport module. +RPC: Registered tcp transport module. +RPC: Registered tcp NFSv4.1 backchannel transport module. +pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +pci_bus 0000:00: resource 7 [mem 0x08000000-0xfebfffff window] +pci_bus 0000:00: resource 8 [mem 0x100000000-0x17fffffff window] +pci 0000:00:01.0: PIIX3: Enabling Passive Release +pci 0000:00:00.0: Limiting direct PCI/PCI transfers +PCI: CLS 0 bytes, default 64 +kvm_intel: VMX not supported by CPU 0 +workingset: timestamp_bits=46 max_order=15 bucket_order=0 +squashfs: version 4.0 (2009/01/31) Phillip Lougher +fuse: init (API version 7.38) +9p: Installing v9fs 9p2000 file system support +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245) +io scheduler mq-deadline registered +io scheduler kyber registered +ACPI: \_SB_.LNKC: Enabled at IRQ 11 +xen:xen_evtchn: Event-channel device installed +ACPI: \_SB_.LNKB: Enabled at IRQ 10 +xen:grant_table: Grant tables using version 1 layout +Grant table initialized +Cannot get hvm parameter CONSOLE_EVTCHN (18): -22! +Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +Non-volatile memory driver v1.3 +ACPI: bus type drm_connector registered +loop: module loaded +Invalid max_queues (4), will use default max: 2. +tun: Universal TUN/TAP device driver, 1.6 +e100: Intel(R) PRO/100 Network Driver +e100: Copyright(c) 1999-2006 Intel Corporation +e1000: Intel(R) PRO/1000 Network Driver +e1000: Copyright (c) 1999-2006 Intel Corporation. +e1000e: Intel(R) PRO/1000 Network Driver +e1000e: Copyright(c) 1999 - 2015 Intel Corporation. +igb: Intel(R) Gigabit Ethernet Network Driver +igb: Copyright (c) 2007-2014 Intel Corporation. +igbvf: Intel(R) Gigabit Virtual Function Network Driver +igbvf: Copyright (c) 2009 - 2012 Intel Corporation. +VMware vmxnet3 virtual NIC driver - version 1.7.0.0-k-NAPI +xen_netfront: Initialising Xen virtual ethernet driver +usbcore: registered new interface driver cdc_ether +usbcore: registered new interface driver cdc_eem +usbcore: registered new interface driver cdc_ncm +usbcore: registered new interface driver r8153_ecm +usbcore: registered new interface driver cdc_acm +cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters +usbcore: registered new interface driver usb-storage +usbcore: registered new interface driver usbserial_generic +usbserial: USB Serial support registered for generic +usbcore: registered new interface driver ch341 +usbserial: USB Serial support registered for ch341-uart +usbcore: registered new interface driver cp210x +usbserial: USB Serial support registered for cp210x +usbcore: registered new interface driver ftdi_sio +usbserial: USB Serial support registered for FTDI USB Serial Device +usbcore: registered new interface driver keyspan +usbserial: USB Serial support registered for Keyspan - (without firmware) +usbserial: USB Serial support registered for Keyspan 1 port adapter +usbserial: USB Serial support registered for Keyspan 2 port adapter +usbserial: USB Serial support registered for Keyspan 4 port adapter +usbcore: registered new interface driver pl2303 +usbserial: USB Serial support registered for pl2303 +usbcore: registered new interface driver usb_serial_simple +usbserial: USB Serial support registered for carelink +usbserial: USB Serial support registered for zio +usbserial: USB Serial support registered for funsoft +usbserial: USB Serial support registered for flashloader +usbserial: USB Serial support registered for google +usbserial: USB Serial support registered for libtransistor +usbserial: USB Serial support registered for vivopay +usbserial: USB Serial support registered for moto_modem +usbserial: USB Serial support registered for motorola_tetra +usbserial: USB Serial support registered for nokia +usbserial: USB Serial support registered for novatel_gps +usbserial: USB Serial support registered for hp4x +usbserial: USB Serial support registered for suunto +usbserial: USB Serial support registered for siemens_mpi +rtc_cmos 00:05: RTC can wake from S4 +rtc_cmos 00:05: registered as rtc0 +rtc_cmos 00:05: alarms up to one day, y3k, 242 bytes nvram, hpet irqs +fail to initialize ptp_kvm +intel_pstate: CPU model not supported +usbcore: registered new interface driver usbhid +usbhid: USB HID core driver +GACT probability NOT on +xt_time: kernel timezone is -0000 +IPVS: Registered protocols (TCP, UDP) +IPVS: Connection hash table configured (size=4096, memory=32Kbytes) +IPVS: ipvs loaded. +IPVS: [rr] scheduler registered. +Initializing XFRM netlink socket +NET: Registered PF_INET6 protocol family +Segment Routing with IPv6 +In-situ OAM (IOAM) with IPv6 +NET: Registered PF_PACKET protocol family +8021q: 802.1Q VLAN Support v1.8 +9pnet: Installing 9P2000 support +NET: Registered PF_VSOCK protocol family +IPI shorthand broadcast: enabled +sched_clock: Marking stable (402156364, -4933103)->(420983909, -23760648) +Clockevents: could not switch to one-shot mode: lapic is not functional. +Could not switch to high resolution mode on CPU 0 +Clockevents: could not switch to one-shot mode: lapic is not functional. +Could not switch to high resolution mode on CPU 1 +tsc: Refined TSC clocksource calibration: 2495.955 MHz +clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x23fa4cd42c8, max_idle_ns: 440795310990 ns +clocksource: Switched to clocksource tsc +Clockevents: could not switch to one-shot mode: lapic is not functional. +Could not switch to high resolution mode on CPU 1 +Clockevents: could not switch to one-shot mode: lapic is not functional. +Could not switch to high resolution mode on CPU 0 +xenbus_probe_frontend: Waiting for devices to initialise: 25s...20s...15s... +random: crng init done +10s...5s...0s... +``` +Steps to reproduce: +Either run the mentioned avocado/functional test, or directly the mentioned QEMU command line >= 50 times +Additional information: +I think it reproduces more easily if the host machine is under load (not quite sure about it, though). + +See this discussion on the mailing list for some more details: + +https://lore.kernel.org/qemu-devel/999a8203f0c800f1305aacdb500dbf6038ebf147.camel@infradead.org/ diff --git a/results/classifier/gemma3:12b/hypervisor/2748 b/results/classifier/gemma3:12b/hypervisor/2748 new file mode 100644 index 00000000..bb2f7985 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2748 @@ -0,0 +1,251 @@ + +Windows specific main loop deadlock when using serial pipe communication +Description of problem: +Attaching WinDBG (or for that matter, any other serial end that sends data quickly enough) causes QEMU to deadlock. +Steps to reproduce: +1. Fire up QEMU with Windows (serial debugging enable) +2. Restart +3. At boot time, plug-in host WinDBG +Additional information: +WinDBG QEMU stacktrace +``` +0:020> g +(34c4.2330): Control-C exception - code 40010005 (first chance) +First chance exceptions are reported before any exception handling. +This exception may be expected and handled. +KERNELBASE!CtrlRoutine+0x1be: +00007ffe`82ace6ce 0f1f440000 nop dword ptr [rax+rax] +0:019> g +(34c4.3b3c): Break instruction exception - code 80000003 (first chance) +ntdll!DbgBreakPoint: +00007ffe`850d4090 cc int 3 +0:017> ~*k + + 0 Id: 34c4.28b8 Suspend: 1 Teb: 0000009f`a24ac000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a27f7388 00007ffe`829e6656 ntdll!NtCreateEvent+0x14 +0000009f`a27f7390 00007ff7`38abcbd6 KERNELBASE!PeekNamedPipe+0xa6 +0000009f`a27f7460 00007ff7`38bb8f11 qemu_system_x86_64!win_chr_pipe_poll+0x84 +0000009f`a27f74d0 00007ff7`38bb93fb qemu_system_x86_64!os_host_main_loop_wait+0x133 +0000009f`a27ffba0 00007ff7`38686c45 qemu_system_x86_64!main_loop_wait+0xce +0000009f`a27ffc00 00007ff7`38ac2f14 qemu_system_x86_64!qemu_main_loop+0x2b +0000009f`a27ffc40 00007ff7`38ac2f52 qemu_system_x86_64!qemu_default_main+0x14 +0000009f`a27ffc80 00007ff7`38bdeede qemu_system_x86_64!SDL_main+0x26 +0000009f`a27ffcb0 00007ff7`3838140a qemu_system_x86_64!__mingw_enum_import_library_names+0x24e +0000009f`a27ffd30 00007ff7`383814f6 qemu_system_x86_64!__tmainCRTStartup+0xea +0000009f`a27ffd70 00007ffe`83ca259d qemu_system_x86_64!mainCRTStartup+0x16 +0000009f`a27ffda0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a27ffdd0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 1 Id: 34c4.2738 Suspend: 1 Teb: 0000009f`a24ae000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a29ffaa8 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a29ffab0 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a29ffd90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a29ffdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 2 Id: 34c4.35e4 Suspend: 1 Teb: 0000009f`a24b0000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a2bffa88 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a2bffa90 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a2bffd70 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a2bffda0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 3 Id: 34c4.24f0 Suspend: 1 Teb: 0000009f`a24b2000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a2dff838 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a2dff840 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a2dffb20 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a2dffb50 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 4 Id: 34c4.2898 Suspend: 1 Teb: 0000009f`a24b4000 Unfrozen "pool" +Child-SP RetAddr Call Site +0000009f`a2fffb58 00007ffe`850997db ntdll!NtWaitForAlertByThreadId+0x14 +0000009f`a2fffb60 00007ffe`829df2e9 ntdll!RtlSleepConditionVariableSRW+0x13b +0000009f`a2fffbe0 00007ffd`cb1c6903 KERNELBASE!SleepConditionVariableSRW+0x29 +0000009f`a2fffc20 00007ffd`cb235399 libglib_2_0_0!g_byte_array_sort_with_data+0x143 +0000009f`a2fffc80 00007ffd`cb234a41 libglib_2_0_0!g_get_num_processors+0x2c9 +0000009f`a2fffce0 00007ffd`cb2696f7 libglib_2_0_0!g_test_get_path+0x51 +0000009f`a2fffd20 00007ffe`8424e634 libglib_2_0_0!g_private_replace+0x117 +0000009f`a2fffd50 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a2fffd80 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a2fffdb0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a2fffde0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 5 Id: 34c4.2ed8 Suspend: 1 Teb: 0000009f`a24b6000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a31ff9b8 00007ffe`829a9cee ntdll!NtWaitForSingleObject+0x14 +0000009f`a31ff9c0 00007ff7`38b9f99f KERNELBASE!WaitForSingleObjectEx+0x8e +0000009f`a31ffa60 00007ff7`38baba83 qemu_system_x86_64!qemu_event_wait+0xe3 +0000009f`a31ffac0 00007ff7`38b9faf2 qemu_system_x86_64!call_rcu_thread+0x6c +0000009f`a31ffb00 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a31ffb50 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a31ffb80 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a31ffbb0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a31ffbe0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 6 Id: 34c4.2980 Suspend: 1 Teb: 0000009f`a24b8000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a35ff888 00007ffe`82dc54a7 win32u!NtUserMsgWaitForMultipleObjectsEx+0x14 +0000009f`a35ff890 00007ffe`71373c70 USER32!MsgWaitForMultipleObjects+0x57 +0000009f`a35ff8d0 00007ffe`71373bc9 gdiplus!BackgroundThreadProc+0x70 +0000009f`a35ff940 00007ffe`83ca259d gdiplus!DllRefCountSafeThreadThunk+0x29 +0000009f`a35ff970 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a35ff9a0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 7 Id: 34c4.3880 Suspend: 1 Teb: 0000009f`a24ba000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a37ff808 00007ffe`829c6849 ntdll!NtWaitForMultipleObjects+0x14 +0000009f`a37ff810 00007ffe`837707ad KERNELBASE!WaitForMultipleObjectsEx+0xe9 +0000009f`a37ffaf0 00007ffe`8377061a combase!WaitCoalesced+0xa9 +0000009f`a37ffd90 00007ffe`8377040f combase!CROIDTable::WorkerThreadLoop+0x5a +0000009f`a37ffde0 00007ffe`83770829 combase!CRpcThread::WorkerLoop+0x57 +0000009f`a37ffe60 00007ffe`83ca259d combase!CRpcThreadCache::RpcWorkerThreadEntry+0x29 +0000009f`a37ffe90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a37ffec0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 8 Id: 34c4.1bd0 Suspend: 1 Teb: 0000009f`a24bc000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a39ffaa8 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a39ffab0 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a39ffd90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a39ffdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 9 Id: 34c4.20fc Suspend: 1 Teb: 0000009f`a24be000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a3bffa78 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a3bffa80 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a3bffd60 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a3bffd90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 10 Id: 34c4.1768 Suspend: 1 Teb: 0000009f`a24c0000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a3dff438 00007ffe`8457a212 win32u!NtUserMsgWaitForMultipleObjectsEx+0x14 +0000009f`a3dff440 00007ffe`8456fa2e shcore!WorkThreadManager::CThread::ThreadProc+0xbf2 +0000009f`a3dff6f0 00007ffe`8456f9f1 shcore!WorkThreadManager::CThread::s_ExecuteThreadProc+0x22 +0000009f`a3dff730 00007ffe`83ca259d shcore!<lambda_9844335fc14345151eefcc3593dd6895>::<lambda_invoker_cdecl>+0x11 +0000009f`a3dff760 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a3dff790 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 11 Id: 34c4.3ac0 Suspend: 1 Teb: 0000009f`a24d6000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a41fead0 00007ffe`8506d249 ntdll!RtlpAllocateHeap+0x835 +0000009f`a41fed30 00007ffe`85134832 ntdll!RtlpAllocateHeapInternal+0x6c9 +0000009f`a41fee30 00007ffe`850ee2e8 ntdll!RtlDebugAllocateHeap+0x102 +0000009f`a41feed0 00007ffe`8506d249 ntdll!RtlpAllocateHeap+0x7f1a8 +0000009f`a41ff130 00007ffe`85059634 ntdll!RtlpAllocateHeapInternal+0x6c9 +0000009f`a41ff230 00007ffe`85058877 ntdll!LdrpAllocateTls+0x108 +0000009f`a41ff300 00007ffe`850a45af ntdll!LdrpInitializeThread+0x6f +0000009f`a41ff3e0 00007ffe`850a44e3 ntdll!_LdrpInitialize+0x93 +0000009f`a41ff460 00007ffe`850a440e ntdll!LdrpInitializeInternal+0x6b +0000009f`a41ff6e0 00000000`00000000 ntdll!LdrInitializeThunk+0xe + + 12 Id: 34c4.3fac Suspend: 1 Teb: 0000009f`a24c4000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a43ff268 00007ffe`85067e65 ntdll!NtWaitForAlertByThreadId+0x14 +0000009f`a43ff270 00007ff7`38b9edcd ntdll!RtlAcquireSRWLockExclusive+0x165 +0000009f`a43ff2e0 00007ff7`386771e6 qemu_system_x86_64!qemu_mutex_lock_impl+0x73 +0000009f`a43ff320 00007ff7`388b5654 qemu_system_x86_64!bql_lock_impl+0x78 +0000009f`a43ff370 00007ff7`388b5b00 qemu_system_x86_64!prepare_mmio_access+0x30 +0000009f`a43ff3b0 00007ff7`388b5c6c qemu_system_x86_64!flatview_read_continue_step+0xa0 +0000009f`a43ff430 00007ff7`388b5db9 qemu_system_x86_64!flatview_read_continue+0x66 +0000009f`a43ff480 00007ff7`388b5e60 qemu_system_x86_64!flatview_read+0xe2 +0000009f`a43ff500 00007ff7`388b5fb6 qemu_system_x86_64!address_space_read_full+0x78 +0000009f`a43ff570 00007ff7`38786ddf qemu_system_x86_64!address_space_rw+0x68 +0000009f`a43ff5c0 00007ffd`c624af05 qemu_system_x86_64!whpx_emu_ioport_callback+0x63 +0000009f`a43ff610 00007ffd`c62523d5 WinHvEmulation!IoPortHandler::NotifyIoPortRead+0x45 +0000009f`a43ff640 00007ffd`c624b916 WinHvEmulation!EmulatorVp::DispatchIoPortOperation+0x159 +0000009f`a43ff690 00007ffd`c624a77f WinHvEmulation!EmulatorVp::TrySimpleIoEmulation+0xc2 +0000009f`a43ff800 00007ffd`c6248caf WinHvEmulation!EmulatorWrapper::TryEmulationHelper<<lambda_6e350ef384ad69a259a7e747c2fadeeb> &>+0xcb +0000009f`a43ff8a0 00007ff7`38787201 WinHvEmulation!WHvEmulatorTryIoEmulation+0x10f +0000009f`a43ff930 00007ff7`38788cd6 qemu_system_x86_64!whpx_handle_portio+0x73 +0000009f`a43ff9a0 00007ff7`38789bd2 qemu_system_x86_64!whpx_vcpu_run+0x4a8 +0000009f`a43ffb20 00007ff7`3878c008 qemu_system_x86_64!whpx_vcpu_exec+0x54 +0000009f`a43ffb60 00007ff7`38b9faf2 qemu_system_x86_64!whpx_cpu_thread_fn+0xfb +0000009f`a43ffbb0 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a43ffc00 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a43ffc30 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a43ffc60 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a43ffc90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 13 Id: 34c4.3ecc Suspend: 1 Teb: 0000009f`a24c6000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a45ff8c8 00007ffe`829a9cee ntdll!NtWaitForSingleObject+0x14 +0000009f`a45ff8d0 00007ffd`e15631e2 KERNELBASE!WaitForSingleObjectEx+0x8e +0000009f`a45ff970 00007ffd`e156b621 WinHvPlatform!WHvApi::Processor::RunVp+0x486 +0000009f`a45ffbe0 00007ff7`38788b9a WinHvPlatform!WHvRunVirtualProcessor+0x31 +0000009f`a45ffc20 00007ff7`38789bd2 qemu_system_x86_64!whpx_vcpu_run+0x36c +0000009f`a45ffda0 00007ff7`3878c008 qemu_system_x86_64!whpx_vcpu_exec+0x54 +0000009f`a45ffde0 00007ff7`38b9faf2 qemu_system_x86_64!whpx_cpu_thread_fn+0xfb +0000009f`a45ffe30 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a45ffe80 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a45ffeb0 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a45ffee0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a45fff10 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 14 Id: 34c4.3d08 Suspend: 1 Teb: 0000009f`a24c8000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a47ff1a8 00007ffe`829a9cee ntdll!NtWaitForSingleObject+0x14 +0000009f`a47ff1b0 00007ffd`e15631e2 KERNELBASE!WaitForSingleObjectEx+0x8e +0000009f`a47ff250 00007ffd`e156b621 WinHvPlatform!WHvApi::Processor::RunVp+0x486 +0000009f`a47ff4c0 00007ff7`38788b9a WinHvPlatform!WHvRunVirtualProcessor+0x31 +0000009f`a47ff500 00007ff7`38789bd2 qemu_system_x86_64!whpx_vcpu_run+0x36c +0000009f`a47ff680 00007ff7`3878c008 qemu_system_x86_64!whpx_vcpu_exec+0x54 +0000009f`a47ff6c0 00007ff7`38b9faf2 qemu_system_x86_64!whpx_cpu_thread_fn+0xfb +0000009f`a47ff710 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a47ff760 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a47ff790 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a47ff7c0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a47ff7f0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 15 Id: 34c4.3eb4 Suspend: 1 Teb: 0000009f`a24ca000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a49ff278 00007ffe`829a9cee ntdll!NtWaitForSingleObject+0x14 +0000009f`a49ff280 00007ffd`e15631e2 KERNELBASE!WaitForSingleObjectEx+0x8e +0000009f`a49ff320 00007ffd`e156b621 WinHvPlatform!WHvApi::Processor::RunVp+0x486 +0000009f`a49ff590 00007ff7`38788b9a WinHvPlatform!WHvRunVirtualProcessor+0x31 +0000009f`a49ff5d0 00007ff7`38789bd2 qemu_system_x86_64!whpx_vcpu_run+0x36c +0000009f`a49ff750 00007ff7`3878c008 qemu_system_x86_64!whpx_vcpu_exec+0x54 +0000009f`a49ff790 00007ff7`38b9faf2 qemu_system_x86_64!whpx_cpu_thread_fn+0xfb +0000009f`a49ff7e0 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a49ff830 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a49ff860 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a49ff890 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a49ff8c0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 16 Id: 34c4.3844 Suspend: 1 Teb: 0000009f`a24cc000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a4bff328 00007ffe`829c6849 ntdll!NtWaitForMultipleObjects+0x14 +0000009f`a4bff330 00007ffd`cb215d94 KERNELBASE!WaitForMultipleObjectsEx+0xe9 +0000009f`a4bff610 00007ffd`cb21607a libglib_2_0_0!g_pattern_match_simple+0x214 +0000009f`a4bff690 00007ffd`cb216612 libglib_2_0_0!g_pattern_match_simple+0x4fa +0000009f`a4bff6e0 00007ffd`cb203740 libglib_2_0_0!g_poll+0x392 +0000009f`a4bffbd0 00007ffd`cb204180 libglib_2_0_0!g_get_monotonic_time+0xac0 +0000009f`a4bffc60 00007ffd`c9eaa829 libglib_2_0_0!g_main_loop_run+0x120 +0000009f`a4bffcb0 00007ffd`e5ab4e2b libspice_server_1!spice_server_init+0x1ca9 +0000009f`a4bffcf0 00007ffe`8424e634 libwinpthread_1!pthread_create_wrapper+0x9b +0000009f`a4bffd30 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a4bffd60 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a4bffd90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a4bffdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + +# 17 Id: 34c4.3b3c Suspend: 1 Teb: 0000009f`a24d8000 Unfrozen +Child-SP RetAddr Call Site +0000009f`c4dffd08 00007ffe`8510735e ntdll!DbgBreakPoint +0000009f`c4dffd10 00007ffe`83ca259d ntdll!DbgUiRemoteBreakin+0x4e +0000009f`c4dffd40 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`c4dffd70 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 18 Id: 34c4.16c4 Suspend: 1 Teb: 0000009f`a24d0000 Unfrozen +Child-SP RetAddr Call Site +0000009f`c53ffb58 00007ffe`850997db ntdll!NtWaitForAlertByThreadId+0x14 +0000009f`c53ffb60 00007ffe`829df2e9 ntdll!RtlSleepConditionVariableSRW+0x13b +0000009f`c53ffbe0 00007ff7`38b9f403 KERNELBASE!SleepConditionVariableSRW+0x29 +0000009f`c53ffc20 00007ff7`38bbc9e5 qemu_system_x86_64!qemu_cond_timedwait_impl+0x92 +0000009f`c53ffc70 00007ff7`38b9faf2 qemu_system_x86_64!worker_thread+0xc9 +0000009f`c53ffce0 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`c53ffd30 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`c53ffd60 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`c53ffd90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`c53ffdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2752 b/results/classifier/gemma3:12b/hypervisor/2752 new file mode 100644 index 00000000..03cc1f90 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2752 @@ -0,0 +1,278 @@ + +Heap use after free in virtio-crypto with vhost-user backend +Description of problem: +An heap-use-after-free happens in virtio-crypto device with vhost-user backend created by a dpdk example program. +Steps to reproduce: +1.Build dpdk vhost-user crypto backend. Following instructions here: [DPDK installation](https://doc.dpdk.org/guides/prog_guide/build-sdk-meson.html) +``` +wget https://fast.dpdk.org/rel/dpdk-24.11.tar.xz +meson setup -Dexamples=all build +cd build +ninja +meson install +cd examples +sudo ./dpdk-vhost_crypto --vdev 'crypto_aesni_mb0' -- --config \(7,0,0\) --socket-file=7,/tmp/my-crypto.sock +``` +After setting up the backend, should see something like: +``` +EAL: Detected CPU lcores: 48 +EAL: Detected NUMA nodes: 2 +EAL: Detected static linkage of DPDK +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: Selected IOVA mode 'PA' +EAL: VFIO support initialized +CRYPTODEV: Creating cryptodev crypto_aesni_mb0 +CRYPTODEV: Initialisation parameters - name: crypto_aesni_mb0,socket id: 0, max queue pairs: 8 +IPSEC_MB: ipsec_mb_create() line 168: IPSec Multi-buffer library version used: 2.0.0 +USER1: Processing on Core 7 started +VHOST_CONFIG: (/tmp/my-crypto.sock) logging feature is disabled in async copy mode +VHOST_CONFIG: (/tmp/my-crypto.sock) vhost-user server: socket created, fd: 213 +VHOST_CONFIG: (/tmp/my-crypto.sock) binding succeeded +``` + +2.Build qemu with ASAN (i.e., --enable-asan) and vhost support (i.e., --enable-vhost-user --enable-vhost-crypto) + +3.Ensure that /dev/hugemaps and /tmp/my-crypto.sock can be accessed. You may need to change their permissions by chmod, or run qemu-system as root. + +4.Run the command below to reproduce UAF. Here, Setting ASAN_OPTIONS=max_malloc_fill_size=0 avoids capturing another unintialized read in vhost_user_backend_init, which happens ealier than the UAF. + +I can reproduce it 7 times in 10 runs, seems to be racing. +``` +cat << EOF | ASAN_OPTIONS=max_malloc_fill_size=0 \ +./qemu-system-x86_64 --enable-kvm -m 512M \ +-object \ +memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on \ +-numa node,memdev=mem -smp cpus=4 -machine q35 -chardev \ +socket,id=chardev0,path=/tmp/my-crypto.sock -object \ +cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 -device \ +virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -display none -qtest \ +stdio +outl 0xcf8 0x80001800 +inw 0xcfc +outl 0xcf8 0x80001814 +outl 0xcfc 0xffffffff +outl 0xcf8 0x80001814 +inl 0xcfc +outl 0xcf8 0x80001814 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80001820 +outl 0xcfc 0xffffffff +outl 0xcf8 0x80001820 +inl 0xcfc +outl 0xcf8 0x80001820 +outl 0xcfc 0xe0004000 +outl 0xcf8 0x80001804 +inw 0xcfc +outl 0xcf8 0x80001804 +outw 0xcfc 0x7 +outl 0xcf8 0x80001804 +inw 0xcfc +writeq 0xe0004023 0x5f5f5f5f5f5f0d00 +writeq 0xe0004015 0x10b2d007a210fff +writeq 0xe0004011 0xb2616007a006425 +writeq 0xe0004011 0x5a5546a2d40b6425 +EOF +``` +Additional information: +Here is the information reported by ASAN: +``` +==2277232==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 0.000000] OPENED +qemu-system-x86_64: warning: vhost-user backend supports VHOST_USER_PROTOCOL_F_CONFIG but QEMU does not. +[R +0.119439] outl 0xcf8 0x80001800 +[S +0.119564] OK +OK +[R +0.119607] inw 0xcfc +[S +0.119667] OK 0x1af4 +OK 0x1af4 +[R +0.119721] outl 0xcf8 0x80001814 +[S +0.119770] OK +OK +[R +0.119817] outl 0xcfc 0xffffffff +[S +0.119889] OK +OK +[R +0.119929] outl 0xcf8 0x80001814 +[S +0.119977] OK +OK +[R +0.120037] inl 0xcfc +[S +0.120090] OK 0xfffff000 +OK 0xfffff000 +[R +0.120140] outl 0xcf8 0x80001814 +[S +0.120165] OK +OK +[R +0.120193] outl 0xcfc 0xe0000000 +[S +0.120242] OK +OK +[R +0.120303] outl 0xcf8 0x80001820 +[S +0.120324] OK +OK +[R +0.120343] outl 0xcfc 0xffffffff +[S +0.120390] OK +OK +[R +0.120431] outl 0xcf8 0x80001820 +[S +0.120487] OK +OK +[R +0.120541] inl 0xcfc +[S +0.120578] OK 0xffffc00c +OK 0xffffc00c +[R +0.120635] outl 0xcf8 0x80001820 +[S +0.120680] OK +OK +[R +0.120747] outl 0xcfc 0xe0004000 +[S +0.120815] OK +OK +[R +0.120858] outl 0xcf8 0x80001804 +[S +0.120881] OK +OK +[R +0.120930] inw 0xcfc +[S +0.120975] OK 0x0000 +OK 0x0000 +[R +0.121017] outl 0xcf8 0x80001804 +[S +0.121053] OK +OK +[R +0.121081] outw 0xcfc 0x7 +[S +0.132297] OK +OK +[R +0.132330] outl 0xcf8 0x80001804 +[S +0.132345] OK +OK +[R +0.132357] inw 0xcfc +[S +0.132373] OK 0x0007 +OK 0x0007 +[R +0.132392] writeq 0xe0004023 0x5f5f5f5f5f5f0d00 +[S +0.132409] OK +OK +[R +0.132419] writeq 0xe0004015 0x10b2d007a210fff +[S +0.132447] OK +OK +[R +0.132460] writeq 0xe0004011 0xb2616007a006425 +[S +0.132480] OK +OK +[R +0.132489] writeq 0xe0004011 0x5a5546a2d40b6425 +qemu-system-x86_64: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on +qemu-system-x86_64: vhost_set_mem_table failed: Invalid argument (22) +qemu-system-x86_64: Failed to write msg. Wrote -1 instead of 52. +qemu-system-x86_64: vhost_set_vring_addr failed: Invalid argument (22) +================================================================= +==2277232==ERROR: AddressSanitizer: heap-use-after-free on address 0x618000000b28 at pc 0x5570e3541a1b bp 0x7fff627ef550 sp 0x7fff627ef548 +READ of size 8 at 0x618000000b28 thread T0 + #0 0x5570e3541a1a in vhost_virtqueue_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1359:33 + #1 0x5570e3562051 in vhost_dev_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:2041:13 + #2 0x5570e37c10c1 in cryptodev_vhost_start_one /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:96:9 + #3 0x5570e37c067f in cryptodev_vhost_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:213:13 + #4 0x5570e34f06ce in virtio_crypto_vhost_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1189:13 + #5 0x5570e34ce991 in virtio_crypto_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1205:5 + #6 0x5570e49725e5 in virtio_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio.c:2242:9 + #7 0x5570e3496356 in virtio_pci_common_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-pci.c:1612:9 + #8 0x5570e4bbdc93 in memory_region_write_accessor /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:497:5 + #9 0x5570e4bbd385 in access_with_adjusted_size /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:573:18 + #10 0x5570e4bbb2f9 in memory_region_dispatch_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:1553:16 + #11 0x5570e4c64dfe in flatview_write_continue_step /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2786:18 + #12 0x5570e4c64694 in flatview_write_continue /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2816:19 + #13 0x5570e4c3b3eb in flatview_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2847:12 + #14 0x5570e4c3aec8 in address_space_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2967:18 + #15 0x5570e375da7c in qtest_process_command /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:532:13 + #16 0x5570e375856d in qtest_process_inbuf /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:776:9 + #17 0x5570e3767b6e in qtest_read /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:788:5 + #18 0x5570e564cafd in qemu_chr_be_write_impl /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:214:9 + #19 0x5570e564cbb9 in qemu_chr_be_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:226:9 + #20 0x5570e5658a35 in fd_chr_read /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fd.c:72:9 + #21 0x5570e500cf6c in qio_channel_fd_source_dispatch /mnt/Hypervisor/qemu/build/master/fuzz/../io/channel-watch.c:84:12 + #22 0x7f8fc04adf7d in g_main_dispatch /home/lmy/glib-2.68.0/_build/../glib/gmain.c:3337:28 + #23 0x7f8fc04adf7d in g_main_context_dispatch /home/lmy/glib-2.68.0/_build/../glib/gmain.c:4055:7 + #24 0x5570e5a014e9 in glib_pollfds_poll /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:287:9 + #25 0x5570e59ffe23 in os_host_main_loop_wait /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:310:5 + #26 0x5570e59ff9ec in main_loop_wait /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:589:11 + #27 0x5570e376f217 in qemu_main_loop /mnt/Hypervisor/qemu/build/master/fuzz/../system/runstate.c:835:9 + #28 0x5570e5679ecc in qemu_default_main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:37:14 + #29 0x5570e5679f17 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:48:12 + #30 0x7f8fbe74f082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16 + #31 0x5570e18f189d in _start (/mnt/Hypervisor/qemu/build/master/fuzz/qemu-system-x86_64+0x2c8b89d) + +0x618000000b28 is located 680 bytes inside of 800-byte region [0x618000000880,0x618000000ba0) +freed by thread T0 here: + #0 0x5570e196dde2 in __interceptor_free /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:111:3 + #1 0x5570e37befc1 in cryptodev_vhost_cleanup /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:45:5 + #2 0x5570e37ce272 in cryptodev_vhost_user_stop /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:86:9 + #3 0x5570e37cd728 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:171:9 + #4 0x5570e5655ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5 + #5 0x5570e564b465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5 + #6 0x5570e5646076 in tcp_chr_disconnect_locked /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-socket.c:482:9 + #7 0x5570e5632534 in tcp_chr_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-socket.c:131:17 + #8 0x5570e564c1f5 in qemu_chr_write_buffer /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:122:15 + #9 0x5570e564b8a2 in qemu_chr_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:186:11 + #10 0x5570e5615f82 in qemu_chr_fe_write_all /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:52:12 + #11 0x5570e49ec22c in vhost_user_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:410:11 + #12 0x5570e4a0e512 in vhost_user_write_sync /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:1141:11 + #13 0x5570e49f84f9 in vhost_user_set_vring_addr /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:1384:12 + #14 0x5570e3543fcb in vhost_virtqueue_set_addr /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:979:9 + #15 0x5570e3540a0b in vhost_virtqueue_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1321:9 + #16 0x5570e3562051 in vhost_dev_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:2041:13 + #17 0x5570e37c10c1 in cryptodev_vhost_start_one /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:96:9 + #18 0x5570e37c067f in cryptodev_vhost_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:213:13 + #19 0x5570e34f06ce in virtio_crypto_vhost_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1189:13 + #20 0x5570e34ce991 in virtio_crypto_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1205:5 + #21 0x5570e49725e5 in virtio_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio.c:2242:9 + #22 0x5570e3496356 in virtio_pci_common_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-pci.c:1612:9 + #23 0x5570e4bbdc93 in memory_region_write_accessor /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:497:5 + #24 0x5570e4bbd385 in access_with_adjusted_size /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:573:18 + #25 0x5570e4bbb2f9 in memory_region_dispatch_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:1553:16 + #26 0x5570e4c64dfe in flatview_write_continue_step /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2786:18 + #27 0x5570e4c64694 in flatview_write_continue /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2816:19 + #28 0x5570e4c3b3eb in flatview_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2847:12 + #29 0x5570e4c3aec8 in address_space_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2967:18 + +previously allocated by thread T0 here: + #0 0x5570e196e04d in malloc /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3 + #1 0x7f8fc04b3dc8 in g_malloc /home/lmy/glib-2.68.0/_build/../glib/gmem.c:106:13 + #2 0x5570e37cdca6 in cryptodev_vhost_user_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:108:30 + #3 0x5570e37cd599 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:164:13 + #4 0x5570e5655ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5 + #5 0x5570e564b465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5 + #6 0x5570e5618d42 in qemu_chr_fe_set_handlers_full /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:283:13 + #7 0x5570e5618674 in qemu_chr_fe_set_handlers /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:297:5 + #8 0x5570e37cb960 in cryptodev_vhost_user_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:220:5 + #9 0x5570e37a4e98 in cryptodev_backend_complete /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev.c:420:9 + #10 0x5570e4eb0c40 in user_creatable_complete /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:28:9 + #11 0x5570e4eb16a8 in user_creatable_add_type /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:125:10 + #12 0x5570e4eb1c74 in user_creatable_add_qapi /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:157:11 + #13 0x5570e378882b in object_option_foreach_add /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:1809:13 + #14 0x5570e378553c in qemu_create_late_backends /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:2029:5 + #15 0x5570e3779efe in qemu_init /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:3726:5 + #16 0x5570e5679f11 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:47:5 + #17 0x7f8fbe74f082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16 + +SUMMARY: AddressSanitizer: heap-use-after-free /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1359:33 in vhost_virtqueue_start +Shadow bytes around the buggy address: + 0x0c307fff8110: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c307fff8120: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c307fff8130: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c307fff8140: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c307fff8150: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +=>0x0c307fff8160: fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd + 0x0c307fff8170: fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c307fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c307fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c307fff81a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c307fff81b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb +==2277232==ABORTING +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2755 b/results/classifier/gemma3:12b/hypervisor/2755 new file mode 100644 index 00000000..469eb3fc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2755 @@ -0,0 +1,12 @@ + +shrink attached rbd size is not allowed by default +Description of problem: + +Steps to reproduce: +1. attach a disk with size 100GiB to a running vm +2. writing some data to the attached disk +3. executing block_resize command and shrink the size to 1GiB + +the result is virtual disk is resized successfully and causing data lost. +Additional information: +Tested QEMU version is 4.2 diff --git a/results/classifier/gemma3:12b/hypervisor/2761 b/results/classifier/gemma3:12b/hypervisor/2761 new file mode 100644 index 00000000..315e26dd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2761 @@ -0,0 +1,9 @@ + +Emulation of x86_64 binary on ARM64 fails with "Unable to find a guest_base to satisfy all guest address mapping requirements" +Description of problem: +Virtualisation fails with error "Unable to find a guest_base to satisfy all guest address mapping requirements" + +``` +file /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash +/nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, BuildID[sha1]=2938b076ebbc4ea582b8eb1ea5c3f65d7a1b6261, stripped +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2769 b/results/classifier/gemma3:12b/hypervisor/2769 new file mode 100644 index 00000000..52fd9dd3 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2769 @@ -0,0 +1,4 @@ + +Ability to set smbios type 3 field "Type" +Additional information: +That's all :) diff --git a/results/classifier/gemma3:12b/hypervisor/279 b/results/classifier/gemma3:12b/hypervisor/279 new file mode 100644 index 00000000..4ce85c33 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/279 @@ -0,0 +1,2 @@ + +x86-64 MTTCG Does not update page table entries atomically diff --git a/results/classifier/gemma3:12b/hypervisor/2800 b/results/classifier/gemma3:12b/hypervisor/2800 new file mode 100644 index 00000000..b8287fb5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2800 @@ -0,0 +1,8 @@ + +-accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334) +Description of problem: +QEMU fails to use -accel i.e., qemu-system-aarch64-unsigned: -accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334) +Steps to reproduce: +1. Execute the above QEMU command line on a macOS Sequia 15.3 +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2818 b/results/classifier/gemma3:12b/hypervisor/2818 new file mode 100644 index 00000000..5a40b72f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2818 @@ -0,0 +1,8 @@ + +Passing `-M microvm` and `-smbios type=11...` results in smbios args being silently dropped +Description of problem: +(reporting as requested by `danpb` on IRC) + +Using the `-machine microvm` flag with the `smbios type=11...` argument results in the smbios options being silently discarded, because the microvm target doesn't seem to support the smbios feature. + +danpb on IRC suggested that passing those two incompatible flags should result in an error. diff --git a/results/classifier/gemma3:12b/hypervisor/2820 b/results/classifier/gemma3:12b/hypervisor/2820 new file mode 100644 index 00000000..97156711 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2820 @@ -0,0 +1,28 @@ + +STOPI CSR Incorrect Value for Virtual Supervisor External Interrupt in QEMU (AIA Extension) +Description of problem: +We are developing a RISC-V core and have implemented tests for the AIA extension. One of these tests reveals a bug when running in QEMU in a bare-metal environment. The issue relates to the value of the STOPI CSR. Although the CSR behaves correctly in most cases, when a virtual supervisor external interrupt is generated using the IMSIC (i.e., both hip.vseip and hie.vseip are set to 1) while executing in supervisor mode with hideleg.vseip set to 0, the STOPI CSR always returns the value 0. However, according to the specifications, it should return 10, which is the major identity number for the virtual supervisor external interrupt. + +According to the RISC-V specs: + +> The value of stopi is zero unless: (a) there is an interrupt that is both pending in sip and enabled in +sie, or, if the hypervisor extension is implemented, both pending in hip and enabled in hie; and (b) +the interrupt is not delegated to a lower privilege level (by hideleg, if the hypervisor extension is +implemented). When there is a pending-and-enabled major interrupt for supervisor level, field IID is +the major identity number of the highest-priority interrupt, and field IPRIO indicates its priority. + +Upon reviewing the QEMU AIA code, I found the following snippet in `qemu/target/riscv/cpu_helper.c` that might be causing the problem: +``` +int riscv_cpu_sirq_pending(CPURISCVState *env) +{ + uint64_t irqs = riscv_cpu_all_pending(env) & env->mideleg & + ~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP); + uint64_t irqs_f = env->mvip & env->mvien & ~env->mideleg & env->sie; + + return riscv_cpu_pending_to_irq(env, IRQ_S_EXT, IPRIO_DEFAULT_S, + irqs | irqs_f, env->siprio); +} +``` +It appears that virtual supervisor (VS) interrupts are being masked (via the `~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP)` operation) when they likely should not be, which could explain why the STOPI CSR does not reflect the correct value. + +Thank you for your time, and please let me know if any details require further clarification or if my interpretation is incorrect. diff --git a/results/classifier/gemma3:12b/hypervisor/2835 b/results/classifier/gemma3:12b/hypervisor/2835 new file mode 100644 index 00000000..b7b4c1bb --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2835 @@ -0,0 +1,123 @@ + +qtest-x86_64/migration-test times out (hangs?) +Description of problem: +The `qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test` always times out, after updating QEMU from 8.2.2 to 9.1.3 on GNU Guix. Here's an excerpt from testlog.txt, attached in full below: +``` +test: qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test +start time: 15:24:17 +duration: 480.01s +result: killed by signal 15 SIGTERM +command: QTEST_QEMU_BINARY=./qemu-system-x86_64 MESON_TEST_ITERATION=1 MALLOC_PERTURB_=66 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 PYTHON=/tmp/guix-build-qemu-9.1.3.drv-0/qemu-9.1.3/b/qemu/pyvenv/bin/python3 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 G_TEST_DBUS_DAEMON=/tmp/guix-build-qemu-9.1.3.drv-0/qemu-9.1.3/tests/dbus-vmstate-daemon.sh UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 /tmp/guix-build-qemu-9.1.3.drv-0/qemu-9.1.3/b/qemu/tests/qtest/migration-test --tap -k +----------------------------------- stdout ----------------------------------- +TAP version 13 +# random seed: R02S840f7fe2af5c1c1e5b9ead2a7f451731 +# Skipping test: userfaultfd not available +1..56 +# Start of x86_64 tests +# Start of migration tests +# Running /x86_64/migration/bad_dest +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming tcp:127.0.0.1:0 -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +ok 1 /x86_64/migration/bad_dest +# slow test /x86_64/migration/bad_dest executed in 0.60 secs +# Running /x86_64/migration/analyze-script +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming tcp:127.0.0.1:0 -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 2 /x86_64/migration/analyze-script +# slow test /x86_64/migration/analyze-script executed in 0.88 secs +# Running /x86_64/migration/vmstate-checker-script +ok 3 /x86_64/migration/vmstate-checker-script # SKIP Test needs two different QEMU versions +# Running /x86_64/migration/validate_uuid +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 -accel qtest +ok 4 /x86_64/migration/validate_uuid +# slow test /x86_64/migration/validate_uuid executed in 32.74 secs +# Running /x86_64/migration/validate_uuid_error +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 22222222-2222-2222-2222-222222222222 2>/dev/null -accel qtest +ok 5 /x86_64/migration/validate_uuid_error +# slow test /x86_64/migration/validate_uuid_error executed in 32.62 secs +# Running /x86_64/migration/validate_uuid_src_not_set +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 22222222-2222-2222-2222-222222222222 2>/dev/null -accel qtest +ok 6 /x86_64/migration/validate_uuid_src_not_set +# slow test /x86_64/migration/validate_uuid_src_not_set executed in 32.73 secs +# Running /x86_64/migration/validate_uuid_dst_not_set +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +ok 7 /x86_64/migration/validate_uuid_dst_not_set +# slow test /x86_64/migration/validate_uuid_dst_not_set executed in 32.74 secs +# Running /x86_64/migration/dirty_ring +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm,dirty-ring-size=4096 -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm,dirty-ring-size=4096 -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 8 /x86_64/migration/dirty_ring +# slow test /x86_64/migration/dirty_ring executed in 33.89 secs +# Running /x86_64/migration/vcpu_dirty_limit +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm,dirty-ring-size=4096 -name dirtylimit-test,debug-threads=on -m 150M -smp 1 -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/vm_serial -drive file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -accel qtest +ok 9 /x86_64/migration/vcpu_dirty_limit +# slow test /x86_64/migration/vcpu_dirty_limit executed in 13.17 secs +# Start of precopy tests +# Running /x86_64/migration/precopy/file +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 10 /x86_64/migration/precopy/file +# slow test /x86_64/migration/precopy/file executed in 33.10 secs +# Start of unix tests +# Running /x86_64/migration/precopy/unix/plain +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 11 /x86_64/migration/precopy/unix/plain +# slow test /x86_64/migration/precopy/unix/plain executed in 33.89 secs +# Running /x86_64/migration/precopy/unix/xbzrle +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 12 /x86_64/migration/precopy/unix/xbzrle +# slow test /x86_64/migration/precopy/unix/xbzrle executed in 59.80 secs +# Start of suspend tests +# Running /x86_64/migration/precopy/unix/suspend/live +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 13 /x86_64/migration/precopy/unix/suspend/live +# slow test /x86_64/migration/precopy/unix/suspend/live executed in 65.90 secs +# Running /x86_64/migration/precopy/unix/suspend/notlive +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 14 /x86_64/migration/precopy/unix/suspend/notlive +# slow test /x86_64/migration/precopy/unix/suspend/notlive executed in 65.09 secs +# End of suspend tests +# Start of tls tests +# Running /x86_64/migration/precopy/unix/tls/psk +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 15 /x86_64/migration/precopy/unix/tls/psk +# slow test /x86_64/migration/precopy/unix/tls/psk executed in 33.28 secs +# Start of x509 tests +# Running /x86_64/migration/precopy/unix/tls/x509/default-host +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +ok 16 /x86_64/migration/precopy/unix/tls/x509/default-host +# slow test /x86_64/migration/precopy/unix/tls/x509/default-host executed in 0.78 secs +# Running /x86_64/migration/precopy/unix/tls/x509/override-host +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +============================================================================== +``` +Steps to reproduce: +1. Run `make check` +Additional information: +[testlog.txt.gz](/uploads/29c9c4f259b255297a6418e8f7493397/testlog.txt.gz) diff --git a/results/classifier/gemma3:12b/hypervisor/2848 b/results/classifier/gemma3:12b/hypervisor/2848 new file mode 100644 index 00000000..33a44783 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2848 @@ -0,0 +1,14 @@ + +i386 max_cpus off by one +Description of problem: +X86 VMs are currently limited to 255 vCPUs (`mc->max_cpus = 255;` in `pc.c`). +The first occurrence i can find of this limit is in d3e9db933f416c9f1c04df4834d36e2315952e42 from 2005 where both `MAX_APICS` and `MAX_CPUS` was set to 255. This is becoming relevant for some people as servers with 256 cores become more available. + +**Can we increase the limit to 256 vCPUs?** +I think so. + +Today, the APIC id limit (see `apic_id_limit` in `x86-common.c`) is based on the CPU id limit. +According to the a comment for `typdef uint32_t apic_id_t;` (see `topology.h`), we can have 256 APICs, but more APICs require x2APIC support. +APIC seems to be no hindrance to increase max_cpus to 256. + +**Can we increase the limit to 512?** Maybe not? We need x2APIC support of which i have no clue. Also there is always a performance risk of exceeding the size at which current data structures work efficiently. diff --git a/results/classifier/gemma3:12b/hypervisor/2850 b/results/classifier/gemma3:12b/hypervisor/2850 new file mode 100644 index 00000000..cb4aa9e5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2850 @@ -0,0 +1,4 @@ + +Available in a version for Windows on arm +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2852 b/results/classifier/gemma3:12b/hypervisor/2852 new file mode 100644 index 00000000..37ffd989 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2852 @@ -0,0 +1,81 @@ + +heap-use-after-free in timer_pending() +Description of problem: +In the QED block driver, the need_check_timer timer is freed in +bdrv_qed_detach_aio_context, but the pointer to the timer is not +set to NULL. This can lead to a use-after-free scenario +in bdrv_qed_drain_begin(). +Steps to reproduce: +1. [test.qed](/uploads/c8820345bfcd562308da99d9f83df3cf/test.qed) +2. ./qemu-img snapshot -q -a test test.qed +Additional information: +<details> +<pre> +./qemu-img snapshot -q -a test test.qed +==21083==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +================================================================= +==21083==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400004ca50 at pc 0x56050d1462b6 bp 0x7fff14d0d870 sp 0x7fff14d0d868 +READ of size 8 at 0x60400004ca50 thread T0 + #0 0x56050d1462b5 in timer_pending /home/gerben/qemu-img_fuzz/build/../util/qemu-timer.c:483:16 + #1 0x56050cddf82e in bdrv_qed_drain_begin /home/gerben/qemu-img_fuzz/build/../block/qed.c:378:32 + #2 0x56050cb9bb65 in bdrv_do_drained_begin /home/gerben/qemu-img_fuzz/build/../block/io.c:364:13 + #3 0x56050cb9ca03 in bdrv_drain_all_begin_nopoll /home/gerben/qemu-img_fuzz/build/../block/io.c:506:9 + #4 0x56050cb96318 in bdrv_graph_wrlock /home/gerben/qemu-img_fuzz/build/../block/graph-lock.c:116:5 + #5 0x56050cd0cbc4 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:294:9 + #6 0x56050cf95dd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #7 0x7f4adeddbefc in __libc_start_main (/lib64/libc.so.6+0x27efc) + #8 0x56050c96a9f9 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120 + +0x60400004ca50 is located 0 bytes inside of 48-byte region [0x60400004ca50,0x60400004ca80) +freed by thread T0 here: + #0 0x56050ca0daef in free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3 + #1 0x56050cde6b86 in bdrv_qed_do_close /home/gerben/qemu-img_fuzz/build/../block/qed.c:619:5 + #2 0x56050cddbe85 in bdrv_qed_close /home/gerben/qemu-img_fuzz/build/../block/qed.c:639:5 + #3 0x56050cd0cbb2 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:290:13 + #4 0x56050cf95dd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #5 0x7f4adeddbefc in __libc_start_main (/lib64/libc.so.6+0x27efc) + +previously allocated by thread T0 here: + #0 0x56050ca0dfa7 in calloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3 + #1 0x7f4adf359670 in g_malloc0 (/lib64/libglib-2.0.so.0+0x5c670) + #2 0x56050cde4bd0 in bdrv_qed_do_open /home/gerben/qemu-img_fuzz/build/../block/qed.c:543:5 + #3 0x56050cde21a2 in bdrv_qed_open_entry /home/gerben/qemu-img_fuzz/build/../block/qed.c:569:16 + #4 0x56050d137706 in coroutine_trampoline /home/gerben/qemu-img_fuzz/build/../util/coroutine-ucontext.c:175:9 + #5 0x7f4adee066cf (/lib64/libc.so.6+0x526cf) + +SUMMARY: AddressSanitizer: heap-use-after-free /home/gerben/qemu-img_fuzz/build/../util/qemu-timer.c:483:16 in timer_pending +Shadow bytes around the buggy address: + 0x0c08800018f0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa + 0x0c0880001900: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa + 0x0c0880001910: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa + 0x0c0880001920: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd + 0x0c0880001930: fa fa 00 00 00 00 01 fa fa fa 00 00 00 00 00 fa +=>0x0c0880001940: fa fa 00 00 00 00 00 fa fa fa[fd]fd fd fd fd fd + 0x0c0880001950: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c0880001960: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c0880001970: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c0880001980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c0880001990: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==21083==ABORTING +</pre> +</details> diff --git a/results/classifier/gemma3:12b/hypervisor/2862 b/results/classifier/gemma3:12b/hypervisor/2862 new file mode 100644 index 00000000..d3675bdc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2862 @@ -0,0 +1,25 @@ + +unable to complete install when i try to load into qemu +Description of problem: +when i load up a vm, i get the message Unable to complete install: 'internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install + installer.start_install(guest, meter=meter) + File "/usr/share/virt-manager/virtinst/install/installer.py", line 695, in start_install + domain = self._create_guest( + ^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest + domain = self.conn.createXML(initial_xml or final_xml, 0) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/lib/python3/dist-packages/libvirt.py", line 4481, in createXML + raise libvirtError('virDomainCreateXML() failed') +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found. If it's important, vmm recognizes my windows 10 iso as a windows 11. +Steps to reproduce: +1.i just tried to use the vm. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2868 b/results/classifier/gemma3:12b/hypervisor/2868 new file mode 100644 index 00000000..375b99bd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2868 @@ -0,0 +1,4 @@ + +amd iommu pte is only 32bits not 64bits. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2869 b/results/classifier/gemma3:12b/hypervisor/2869 new file mode 100644 index 00000000..688f6ed4 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2869 @@ -0,0 +1,4 @@ + +enable guest mode at amd iommu +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2874 b/results/classifier/gemma3:12b/hypervisor/2874 new file mode 100644 index 00000000..513be3f4 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2874 @@ -0,0 +1,10 @@ + +AMD Ryzen 9950x with -smp option yields "warning: This family of AMD CPU doesn't support hyperthreading" +Description of problem: +When using the above -smp option (`-smp 32,sockets=1,dies=1,clusters=1,cores=16,threads=2`), which should be valid for the Ryzen 9950X 16 cores / 32 threads CPU, QEMU prints: +``` +qemu-system-x86_64: warning: This family of AMD CPU doesn't support hyperthreading(2). Please configure -smp options properly or try enabling topoext feature. +``` +This is unexpected. This CPU should support hyperthreading out of the box, it seems. +Steps to reproduce: +1. Run command above on Ryzen 9950X or similar CPU. diff --git a/results/classifier/gemma3:12b/hypervisor/2877 b/results/classifier/gemma3:12b/hypervisor/2877 new file mode 100644 index 00000000..da5b85dd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2877 @@ -0,0 +1,2 @@ + +Windows Hypervisor Acceleration does not work in Qemu 9.5.20 on Windows 11 24H2 Host diff --git a/results/classifier/gemma3:12b/hypervisor/2880 b/results/classifier/gemma3:12b/hypervisor/2880 new file mode 100644 index 00000000..9bdb6dc3 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2880 @@ -0,0 +1,4 @@ + +how to migrate storage live for the vm with vhostuser disk +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2881 b/results/classifier/gemma3:12b/hypervisor/2881 new file mode 100644 index 00000000..76a89c3b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2881 @@ -0,0 +1,11 @@ + +segfault on loadvm after migrate_set_capability multifd on +Description of problem: +A segfault occurs when running `loadvm` having set `migrate_set_capability multifd on` from the monitor. +EDIT: also `savevm` segfaults. +Steps to reproduce: +1. Take a snapshot with `savevm test` +2. From the monitor run `migrate_set_capability multifd on` +3. Try to restore the snapshot with `loadvm test` +Additional information: +Sorry for not having triaged this much, I think it is worth reporting anyway. diff --git a/results/classifier/gemma3:12b/hypervisor/2882 b/results/classifier/gemma3:12b/hypervisor/2882 new file mode 100644 index 00000000..79fd0569 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2882 @@ -0,0 +1,91 @@ + +Reading ACPI info via fw_cfg in SVSM causes Linux to panic +Description of problem: +We could use some help from a Qemu expert with an Qemu/ACPI/Linux related problem, +working on Coconut SVSM. + +**See https://github.com/coconut-svsm/svsm/issues/646** + +Coconut has code to read ACPI information via fw_cfg, and extract the number of guest CPUs from that. +That code has been used in the past, but since igvm became the default launch method for SVSM, it +was only used in corner-cases, while the information were obtained in some other way (igmv parameter). +Now a commit switches back to the fw_cfg+ACPI method. The information returned by it is correct, but +strangely Linux (guest) is spitting out ACPI related errors and crashes in some cases before reaching user-space. We do not have any clue how this can be related other than through Qemu behavior. +There is no direct way how SVSM can influence the ACPI related behavior of the Linux +guest kernel. + +The problem seems to be caused by simply reading the ACPI data. + +Reverting the bad commit and simply calling the original fw_cfg acpi function causes problems for Linux. +Steps to reproduce: +Boot SVSM bases CVM. SVSM and OVMF boot OK, then Linux prints these errors in some scenarios panics: +``` +[...] +[ 1.857709] ACPI: Added _OSI(Processor Aggregator Device) +[ 1.859436] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 1.860867] ACPI Error: AE_BAD_ADDRESS, Unable to initialize fixed events (20240827/evevent-53) +[ 1.862709] ACPI: Unable to start the ACPI Interpreter +[ 1.863708] ACPI Error: Could not remove SCI handler (20240827/evmisc-251) +[ 1.864942] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MT +X_Namespace] (0x1) (20240827/utmutex-252) +[ 1.866715] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MTX_Tables] (0x2) (20240827/utmutex-252) +[ 1.869722] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired, cannot release (20240 +827/utmutex-289) +[ 1.870826] iommu: Default domain type: Translated +[ 1.871710] iommu: DMA domain TLB invalidation policy: lazy mod +[...] +[ 2.672635] io scheduler bfq registered +[ 2.675679] atomic64_test: passed for x86-64 platform with CX8 and with SSE +[ 2.677596] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 2.679264] ------------[ cut here ]------------ +[ 2.680284] refcount_t: addition on 0; use-after-free. +[ 2.681477] WARNING: CPU: 3 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 +[ 2.683261] Modules linked in: +[ 2.683929] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.6-200.fc41.x86_64 #1 +[ 2.685608] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202502-39-gb +483f751 02/02/2022 +[ 2.687729] RIP: 0010:refcount_warn_saturate+0xe5/0x110 +[ 2.688853] Code: e3 7f ff 0f 0b e9 fb 0a 8a 00 80 3d 15 9f 23 02 00 0f 85 5e ff ff ff 48 c7 c7 30 7b e7 8c c6 05 01 9f 23 02 01 e8 fb e2 7f ff <0f> 0b e9 d4 0a 8a 00 48 c7 c7 88 7b e7 8c + c6 05 e5 9e 23 02 01 e8 +[ 2.692768] RSP: 0018:ffffb2ed0001fd90 EFLAGS: 00010282 +[ 2.693894] RAX: 0000000000000000 RBX: ffff975b81060a80 RCX: ffffffff8d967448 +[ 2.695410] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001 +[ 2.696923] RBP: ffffb2ed0001fe38 R08: 0000000000000000 R09: 0720072007200720 +[ 2.698439] R10: 0720072007200720 R11: 0720072007200720 R12: ffff975b81060a80 +[ 2.699955] R13: ffffb2ed0001fe78 R14: 00000000000000dc R15: 00000000000001df +[ 2.701461] FS: 0000000000000000(0000) GS:ffff975cf7d80000(0000) knlGS:0000000000000000 +[ 2.703179] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 2.704400] CR2: 00007f1c1658a3c8 CR3: 000800006082c000 CR4: 00000000003506f0 +[ 2.705910] Call Trace: +[ 2.706451] <TASK> +[ 2.706922] ? srso_return_thunk+0x5/0x5f +[ 2.707820] ? show_trace_log_lvl+0x255/0x2f0 +[ 2.708783] ? show_trace_log_lvl+0x255/0x2f0 +[ 2.709712] ? kobject_get+0x68/0x70 +[ 2.710492] ? refcount_warn_saturate+0xe5/0x110 +[ 2.711480] ? __warn.cold+0x93/0xfa +[ 2.712268] ? refcount_warn_saturate+0xe5/0x110 +[ 2.713262] ? report_bug+0xff/0x140 +[ 2.714036] ? handle_bug+0x58/0x90 +[ 2.714779] ? exc_invalid_op+0x17/0x70 +[ 2.715617] ? asm_exc_invalid_op+0x1a/0x20 +[ 2.716526] ? refcount_warn_saturate+0xe5/0x110 +[ 2.717507] kobject_get+0x68/0x70 +[ 2.718266] kobject_add_internal+0x32/0x250 +[ 2.719196] kobject_add+0x96/0xc0 +[ 2.719923] kobject_create_and_add+0xa3/0xc0 +[ 2.720851] bgrt_init+0x77/0xc0 +[ 2.721578] ? __pfx_bgrt_init+0x10/0x10 +[ 2.722418] do_one_initcall+0x5b/0x310 +[ 2.723272] do_initcalls+0x147/0x170 +[ 2.724086] ? __pfx_kernel_init+0x10/0x10 +[ 2.725174] kernel_init_freeable+0xfb/0x130 +[ 2.726114] kernel_init+0x1a/0x140 +[ 2.726883] ret_from_fork+0x34/0x50 +[ 2.727679] ? __pfx_kernel_init+0x10/0x10 +[ 2.728580] ret_from_fork_asm+0x1a/0x30 +[ 2.729429] </TASK> +[ 2.729926] ---[ end trace 0000000000000000 ]--- +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2892 b/results/classifier/gemma3:12b/hypervisor/2892 new file mode 100644 index 00000000..58221121 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2892 @@ -0,0 +1,2 @@ + +Outdated documentation about MicroVMs diff --git a/results/classifier/gemma3:12b/hypervisor/2894 b/results/classifier/gemma3:12b/hypervisor/2894 new file mode 100644 index 00000000..59a96046 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2894 @@ -0,0 +1,26 @@ + +There is a bug in versions 2025-02-10 and later that causes virtual machines to be created with incorrect SMP settings with warnings about TCG features when setting more than 2 cores with the smp option in the default TCG acceleration (see main text). +Description of problem: +When using qemu-system-x86_64 in versions 9.2.50 and later, if you create a virtual machine with 2 or more cores using the smp option, + +``` +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1] +``` +The log will be displayed as many as the number of cores you have enabled, and the created virtual machine will be displayed as having a 1-core CPU with the number of cores you have enabled. +* I have not tested whether the same symptom occurs on versions 9.2.50 and later for other environments (Linux and the WoA version released on March 26th). +Steps to reproduce: +1. Create a virtual machine with more than two cores using TCG acceleration, which is the default acceleration, by using options such as 'qemu-system-x86_64 -smp 2' or 'qemu-system-x86_64 -smp sockets=1,cores=2,threads=1'. +2. 'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]' and +'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1]' +The log is generated as many as the number of cores set and the virtual machine is created. +3. When checking the CPU information of the booted virtual machine, it does not show that there is one CPU with the specified number of cores, but rather that there is a single core CPU with the specified number of cores. +Additional information: +``` +>qemu-system-x86_64 -M q35 -smp 2 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\Program Files\qemu\share\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime +``` + +``` +>qemu-system-x86_64 -M q35 -smp 4 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\Program Files\qemu\share\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime +``` + diff --git a/results/classifier/gemma3:12b/hypervisor/2910 b/results/classifier/gemma3:12b/hypervisor/2910 new file mode 100644 index 00000000..2b3e7c32 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2910 @@ -0,0 +1,6 @@ + +SME2 support for aarch64? +Additional information: +We've noticed that most `SME2` instructions work, despite `ARM_HWCAP2_A64_SME2` not being set. + +Cheers, Pedro diff --git a/results/classifier/gemma3:12b/hypervisor/2913 b/results/classifier/gemma3:12b/hypervisor/2913 new file mode 100644 index 00000000..b8feda08 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2913 @@ -0,0 +1,2 @@ + +vmapple machine unusable with macOS 15.4 diff --git a/results/classifier/gemma3:12b/hypervisor/2914 b/results/classifier/gemma3:12b/hypervisor/2914 new file mode 100644 index 00000000..2e488d97 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2914 @@ -0,0 +1,16 @@ + +JRE fails (SIGSEGV) on x86 Ubuntu 24.04 LTS emulated on Apple Silicon M2 ARM +Description of problem: +JRE (HotSpot Runtime) errors with SIGSEGV on x86 Linux Ubuntu 24.04.2 LTS when it is emulated on Apple Silicon M2. In this case, JRE is being triggered by SBT that is running Scala source code. + +This could be a Qemu issue, an OpenJDK issue, an Apple issue, etc. - Let me know if this is the wrong place/not under the purview of Qemu and I'll post it somewhere else. +Steps to reproduce: +I am attempting to run a Scala project (https://github.com/ucb-bar/chipyard) on a x86 machine emulated on an Apple Silicon device. The project build flow fails on step 5 when Scala sources are compiled and run. You can reproduce the issue by running Chipyard's recommended setup flow here: + +https://chipyard.readthedocs.io/en/stable/Chipyard-Basics/Initial-Repo-Setup.html#default-requirements-installation + +Then instead of running the given build-setup command in the tutorial, run `./build-setup.sh riscv-tools -s 3 -s 8 -s 7 -s 8 -s 9 -s 10 --use-lean-conda` in order to skip the irrelevant setup steps. + +The SBT build config is in the project's base directory under build.sbt. There is a commonSettings sequence that is inherited by each subsequent project. The flow: line 409 of common.mk is triggered by line 257 & 258 of build-setup.sh, which then triggers SBT with some arguments passed into the SBT executable. +Additional information: +Extensive crash logs and attempts to solve the issue has been documented at this issue on UTM's GitHub: https://github.com/utmapp/UTM/issues/7070 diff --git a/results/classifier/gemma3:12b/hypervisor/2918 b/results/classifier/gemma3:12b/hypervisor/2918 new file mode 100644 index 00000000..98ed212d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2918 @@ -0,0 +1,2 @@ + +qemu-system-hppa hangs on 64bit installations (machine -C3700) diff --git a/results/classifier/gemma3:12b/hypervisor/2928 b/results/classifier/gemma3:12b/hypervisor/2928 new file mode 100644 index 00000000..ad3e54de --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2928 @@ -0,0 +1,57 @@ + +Segmentation fault in most qemu-system commands on macOS ARM +Description of problem: +Most qemu-system binaries produce a segmentation fault: +``` +raptor@fnord rust_os % qemu-system-x86_64 +zsh: segmentation fault qemu-system-x86_64 +raptor@fnord rust_os % qemu-system-mips +zsh: segmentation fault qemu-system-mips +raptor@fnord rust_os % qemu-system-sparc +zsh: segmentation fault qemu-system-sparc +... +``` + +Some of them work properly: +``` +raptor@fnord rust_os % qemu-system-aarch64 +qemu-system-aarch64: No machine specified, and there is no default +Use -machine help to list supported machines +raptor@fnord rust_os % qemu-system-arm +qemu-system-arm: No machine specified, and there is no default +Use -machine help to list supported machines +raptor@fnord rust_os % qemu-system-avr +qemu-system-avr: No machine specified, and there is no default +Use -machine help to list supported machines +... +``` +Steps to reproduce: +1. Install qemu via homebrew +2. Run `qemu-system-x86_64` +3. A segmentation fault error is produced +Additional information: +``` +raptor@fnord ~ % brew config +HOMEBREW_VERSION: 4.4.32 +ORIGIN: https://github.com/Homebrew/brew +HEAD: 12a3d4a6f1eedf483855716b989d828443438f79 +Last commit: 18 hours ago +Branch: stable +Core tap JSON: 23 Apr 08:36 UTC +Core cask tap JSON: 23 Apr 08:36 UTC +HOMEBREW_PREFIX: /opt/homebrew +HOMEBREW_CASK_OPTS: [] +HOMEBREW_MAKE_JOBS: 8 +Homebrew Ruby: 3.3.8 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.8/bin/ruby +CPU: octa-core 64-bit arm_ibiza +Clang: 16.0.0 build 1600 +Git: 2.39.5 => /Library/Developer/CommandLineTools/usr/bin/git +Curl: 8.7.1 => /usr/bin/curl +macOS: 15.3.2-arm64 +CLT: 16.2.0.0.1.1733547573 +Xcode: N/A +Rosetta 2: false + +raptor@fnord ~ % brew doctor +Your system is ready to brew. +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2938 b/results/classifier/gemma3:12b/hypervisor/2938 new file mode 100644 index 00000000..0fdbfa71 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2938 @@ -0,0 +1,12 @@ + +10.0.0 HVF x86_64 regression: can't boot NetBSD 10.1 with -smp 2 +Description of problem: +Under 9.2.3, a NetBSD/amd64 10.1 guest with `-smp 2` booted and ran fine. + +Under 10.0.0, the same guest never finishes loading the kernel. It looks like it's retrying many times per second, possibly even reloading the NetBSD boot loader each time, though it's redrawing so fast I can't tell for sure. (I'll attempt to link to an asciinema capture shortly.) `-smp 1` lets the machine come up. + +For comparison, a NetBSD/aarch64 10.1 with `-smp 4` runs with `-accel hvf` under macOS/aarch64 15.4.1 just as well with 10.0.0 as it did with 9.2.3. +Steps to reproduce: +1. With x86 macOS host and NetBSD guest (possibly a wider range than the exact versions I'm currently using), attempt to boot NetBSD with `-smp 2` +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/2977 b/results/classifier/gemma3:12b/hypervisor/2977 new file mode 100644 index 00000000..ab4d0e2f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2977 @@ -0,0 +1,12 @@ + +QEMU SVM VMCB exit_code is uint32_t when AMD spec requires uint64_t +Description of problem: +QEMU's SVM implementation incorrectly uses a 32-bit parameter for the exit code in the `cpu_vmexit` function, despite the AMD SVM specification requiring a 64-bit exit code field in the VMCB (Virtual Machine Control Block). + +I think the issue is in `target/i386/svm.c` in the `cpu_vmexit` function. + +The `exit_code` parameter is declared as `uint32_t` but should be `uint64_t` according to the AMD SVM specification. This causes exit codes to be truncated to 32 bits, resulting in values like 0xffff_ffff instead of the expected 0xffff_ffff_ffff_ffff. +Steps to reproduce: + +Additional information: +[this](https://stackoverflow.com/questions/79632531/qemu-svm-vmcb-exit-code-is-uint32-t-when-amd-spec-requires-uint64-t?noredirect=1#comment140448815_79632531) question I posted on stack overflow diff --git a/results/classifier/gemma3:12b/hypervisor/2980 b/results/classifier/gemma3:12b/hypervisor/2980 new file mode 100644 index 00000000..0b8f4dc6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2980 @@ -0,0 +1,265 @@ + +QEMU Crashes During Snapshot: bdrv_co_write_req_prepare Assertion child->perm & BLK_PERM_WRITE Failed +Description of problem: +After taking a external snapshot (w/ memory state) with libvirt, the QEMU process crashed with an assertion + +``` +qemu-system-x86_64: ../block/io.c:2052: bdrv_co_write_req_prepare: Assertion `child->perm & BLK_PERM_WRITE` failed. +``` +Steps to reproduce: +1. Start the qemu process +2. Take an external (w/ memory) snapshot by libvirt Python API + + ```python + domain.snapshotCreateXML(<xml_string>, + libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_ATOMIC | + libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT | + libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_LIVE) + ``` + +3. The qemu process crashed by hitting the assertion +Additional information: +Libvirt domain XML +```xml +<domain type='kvm'> + <name>1a3dabc5-c33b-4308-acc5-2245f3b64163</name> + <uuid>1a3dabc5-c33b-4308-acc5-2245f3b64163</uuid> + <metadata xmlns:qvs="http://www.qnap.com/schemas/qvs/1.0"> + </metadata> + <memory unit='KiB'>16777216</memory> + <currentMemory unit='KiB'>16777216</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static' cpuset='0-23'>5</vcpu> + <sysinfo type='smbios'> + <system> + <entry name='manufacturer'>qemu</entry> + <entry name='product'>qemu</entry> + </system> + </sysinfo> + <os> + <type arch='x86_64' machine='pc-i440fx-7.0'>hvm</type> + <boot dev='cdrom'/> + <boot dev='hd'/> + <bootmenu enable='no'/> + <smbios mode='sysinfo'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'> + <topology sockets='1' dies='1' cores='5' threads='1'/> + <numa> + <cell id='0' cpus='0-4' memory='16777216' unit='KiB' memAccess='private'/> + </numa> + </cpu> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/QVS/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='writeback'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747803601' startupPolicy='optional'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747630800'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747371601'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747198801'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747026001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1746594001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1746421201'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1745557200'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1745211600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1744174801'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1743570001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1743138001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742965201'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742360400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742187600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741928400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741755601'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741323600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740718800'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740546000'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740373200'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740114000'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739941201'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739768400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739509200'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739336400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739163600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1738904400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1738558801'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1724816945'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1724045214_1'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1721622169'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.img'/> + <backingStore/> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + <target dev='vdb' bus='virtio'/> + <serial>1a3dabc5c33b4308ac01</serial> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source startupPolicy='optional'/> + <target dev='hda' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0' model='nec-xhci' ports='6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:a2:a4:e3'/> + <source bridge='qvs0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <channel type='unix'> + <source mode='bind' path='/QVS/var/lib/libvirt/qemu/1a3dabc5-c33b-4308-acc5-2245f3b64163.agent'/> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <tpm model='tpm-tis'> + <backend type='emulator' version='2.0'/> + </tpm> + <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' keymap='en-us'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <graphics type='spice' autoport='yes' listen='127.0.0.1' keymap='en-us'> + <listen type='address' address='127.0.0.1'/> + <image compression='off'/> + <jpeg compression='never'/> + <zlib compression='never'/> + <playback compression='off'/> + <streaming mode='all'/> + </graphics> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <audio id='1' type='spice'/> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </memballoon> + </devices> +</domain> +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2981 b/results/classifier/gemma3:12b/hypervisor/2981 new file mode 100644 index 00000000..6fb71a41 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2981 @@ -0,0 +1,26 @@ + +Assert error with accel=hvf:tcg when hvf is unavailable +Description of problem: +Trying to start qemu with `-machine virt,accel=hvf:tcg` in a Mac OS guest under Mac OS host, both arm64. I expect it to try hvf (unavailable - nested virtualization not supported) and fallback to tcg. Documentation for accel option says "If there is more than one accelerator specified, the next one is used if the previous one fails to initialize." This works fine with kvm, but for hvf it crashes in some auxiliary function when trying it: + +``` +% qemu-system-aarch64 -machine virt,accel=hvf:tcg +qemu-system-aarch64: Error: ret = HV_UNSUPPORTED (0xfae9400f, at ../target/arm/hvf/hvf.c:949) +``` + +Stack trace +``` + * frame #0: 0x0000000193a18388 libsystem_kernel.dylib`__pthread_kill + 8 + frame #1: 0x0000000193a5188c libsystem_pthread.dylib`pthread_kill + 296 + frame #2: 0x000000019395ac60 libsystem_c.dylib`abort + 124 + frame #3: 0x00000001005ee7f4 qemu-system-aarch64`assert_hvf_ok_impl + 92 + frame #4: 0x000000010032a550 qemu-system-aarch64`hvf_arm_get_max_ipa_bit_size + 64 + frame #5: 0x0000000100334928 qemu-system-aarch64`virt_hvf_get_physical_address_range + 68 + frame #6: 0x00000001005ee9b8 qemu-system-aarch64`hvf_accel_init + 68 + frame #7: 0x00000001002ef8e4 qemu-system-aarch64`accel_init_machine + 92 + frame #8: 0x00000001002a6640 qemu-system-aarch64`do_configure_accelerator + 208 + frame #9: 0x0000000100782bdc qemu-system-aarch64`qemu_opts_foreach + 112 + frame #10: 0x00000001002a3180 qemu-system-aarch64`qemu_init + 11344 + frame #11: 0x00000001006ea76c qemu-system-aarch64`main + 36 + frame #12: 0x00000001936b2b4c dyld`start + 6000 +``` diff --git a/results/classifier/gemma3:12b/hypervisor/2984 b/results/classifier/gemma3:12b/hypervisor/2984 new file mode 100644 index 00000000..09d9fdcd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/2984 @@ -0,0 +1,54 @@ + +CPU hotplug crashed the guest when using virt-type as qemu! +Description of problem: +Guest is getting crashing and getting into shutoff state when I am trying to hotplug much more cpus than present in the host! This is happening only when i give virt-type as qemu. +Additional information: +Tried reproducing while attaching gdb shows below backtrace which happened after hotplugging 249 CPUs in TCG mode: + +``` +Thread 261 "CPU 249/TCG" received signal SIGABRT, Aborted. +[Switching to Thread 0x7ff97c00ea20 (LWP 51567)] +0x00007fff84cac3e8 in __pthread_kill_implementation () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +(gdb) bt +#0 0x00007fff84cac3e8 in __pthread_kill_implementation () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#1 0x00007fff84c46ba0 in raise () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#2 0x00007fff84c29354 in abort () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#3 0x00007fff850f1e30 in g_assertion_message () from target:/lib64/libglib-2.0.so.0 +#4 0x00007fff850f1ebc in g_assertion_message_expr () from target:/lib64/libglib-2.0.so.0 +#5 0x00000001376c6f00 in tcg_region_initial_alloc__locked (s=0x7fff7c000f30) at ../tcg/region.c:396 +#6 0x00000001376c6fa8 in tcg_region_initial_alloc (s=0x7fff7c000f30) at ../tcg/region.c:402 +#7 0x00000001376dae08 in tcg_register_thread () at ../tcg/tcg.c:1011 +#8 0x000000013768b7e4 in mttcg_cpu_thread_fn (arg=0x143e884f0) at ../accel/tcg/tcg-accel-ops-mttcg.c:77 +#9 0x0000000137bbb2d0 in qemu_thread_start (args=0x143b4aff0) at ../util/qemu-thread-posix.c:542 +#10 0x00007fff84ca9be0 in start_thread () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#11 0x00007fff84d4ef3c in __clone3 () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +(gdb) +``` + +which points to below code: + +``` +/* + * Perform a context's first region allocation. + * This function does _not_ increment region.agg_size_full. + */ +static void tcg_region_initial_alloc__locked(TCGContext *s) +{ + bool err = tcg_region_alloc__locked(s); + g_assert(!err); +} +``` + +Here, tcg_region_alloc__locked returns true on failure when max region allocation is reached and therefore intentionally asserted as TCG can't proceed without it. + +``` +static bool tcg_region_alloc__locked(TCGContext *s) +{ + if (region.current == region.n) { + return true; + } + tcg_region_assign(s, region.current); + region.current++; + return false; +} +``` diff --git a/results/classifier/gemma3:12b/hypervisor/319 b/results/classifier/gemma3:12b/hypervisor/319 new file mode 100644 index 00000000..d383966c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/319 @@ -0,0 +1,2 @@ + +Openjdk11+ fails to install on s390x diff --git a/results/classifier/gemma3:12b/hypervisor/320 b/results/classifier/gemma3:12b/hypervisor/320 new file mode 100644 index 00000000..bad639ff --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/320 @@ -0,0 +1,2 @@ + +Corsair iCUE Install Fails, qemu VM Reboots diff --git a/results/classifier/gemma3:12b/hypervisor/337 b/results/classifier/gemma3:12b/hypervisor/337 new file mode 100644 index 00000000..ca763ad0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/337 @@ -0,0 +1,2 @@ + +QEMU emulator version 6.0.50 Failure with nested FreeBSD bhyve diff --git a/results/classifier/gemma3:12b/hypervisor/343 b/results/classifier/gemma3:12b/hypervisor/343 new file mode 100644 index 00000000..db6ba618 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/343 @@ -0,0 +1,2 @@ + +madvise reports success, but doesn't implement WIPEONFORK. diff --git a/results/classifier/gemma3:12b/hypervisor/344 b/results/classifier/gemma3:12b/hypervisor/344 new file mode 100644 index 00000000..3ccb6f6d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/344 @@ -0,0 +1,2 @@ + +Option "-loadvm" cannot load VM snapshot, created from QMP API diff --git a/results/classifier/gemma3:12b/hypervisor/361 b/results/classifier/gemma3:12b/hypervisor/361 new file mode 100644 index 00000000..cdf300db --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/361 @@ -0,0 +1,2 @@ + +-cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/gemma3:12b/hypervisor/366 b/results/classifier/gemma3:12b/hypervisor/366 new file mode 100644 index 00000000..563fc30b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/366 @@ -0,0 +1,2 @@ + +How to make OVMF diff --git a/results/classifier/gemma3:12b/hypervisor/403 b/results/classifier/gemma3:12b/hypervisor/403 new file mode 100644 index 00000000..db4f31f8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/403 @@ -0,0 +1,2 @@ + +MTE false positives for unaligned accesses diff --git a/results/classifier/gemma3:12b/hypervisor/414 b/results/classifier/gemma3:12b/hypervisor/414 new file mode 100644 index 00000000..a6260b3e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/414 @@ -0,0 +1,2 @@ + +Error handling: Use &error_abort instead of NULL for errp parameters for may-not-fail invocations diff --git a/results/classifier/gemma3:12b/hypervisor/420 b/results/classifier/gemma3:12b/hypervisor/420 new file mode 100644 index 00000000..42539527 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/420 @@ -0,0 +1,2 @@ + +Some x86_64 SSE operations have incorrect/erratic behaviours diff --git a/results/classifier/gemma3:12b/hypervisor/427 b/results/classifier/gemma3:12b/hypervisor/427 new file mode 100644 index 00000000..4aed257c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/427 @@ -0,0 +1,2 @@ + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction diff --git a/results/classifier/gemma3:12b/hypervisor/430 b/results/classifier/gemma3:12b/hypervisor/430 new file mode 100644 index 00000000..89544539 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/430 @@ -0,0 +1,2 @@ + +Microsoft Hyper-V acceleration not working diff --git a/results/classifier/gemma3:12b/hypervisor/439 b/results/classifier/gemma3:12b/hypervisor/439 new file mode 100644 index 00000000..0a0f0fd5 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/439 @@ -0,0 +1,2 @@ + +Hard crash - qemu-6.0.0 with windows 10 guest diff --git a/results/classifier/gemma3:12b/hypervisor/453 b/results/classifier/gemma3:12b/hypervisor/453 new file mode 100644 index 00000000..3571a707 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/453 @@ -0,0 +1,4 @@ + +tests/acceptance: Allow to overwrite smp and memory values set by `avocado_qemu.LinuxTest` +Additional information: +Refer to the discussion in https://lore.kernel.org/qemu-devel/20210621080824.789274-1-eric.auger@redhat.com/ diff --git a/results/classifier/gemma3:12b/hypervisor/462 b/results/classifier/gemma3:12b/hypervisor/462 new file mode 100644 index 00000000..15f21b1b --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/462 @@ -0,0 +1,44 @@ + +mirror: the block-job-cancel command can put qemu to the endless error loop +Description of problem: +If the destination VM will crash (or network is down) right before the completion of the block device mirroring job (`block-job-cancel`), then there will be a possibility to put QEMU in the error loop. +Steps to reproduce: +1. Run both QEMU VMs: source + target. +2. On the target side prepare NBD server for blockdev mirroring process by using QMP commands similar to the one below: +``` +{"execute": "nbd-server-start", "arguments": { "addr": { "data": { "host": "::", "port": "49153" }, "type": "inet" } } } +{ "execute": "nbd-server-add", "arguments": { "device": "drive_main01", "writable": true } } +``` +3. On the source side, prepare VM for the migration and start driver mirror job: +``` +{"execute":"migrate-set-capabilities","arguments":{"capabilities":[{"capability":"pause-before-switchover","state":true}]}} +{ "execute": "drive-mirror", "arguments": { "device": "drive_main01", "mode": "existing", "job-id": "job0", "target": "nbd:127.0.0.1:49153:exportname=drive_main01", "sync": "top", "on-source-error": "stop", "on-target-error": "stop", "format": "raw", "speed": 0 } } +``` +4. On the source side wait for the `BLOCK_JOB_READY` event: +``` +{"timestamp": {"seconds": 1625586327, "microseconds": 833805}, "event": "BLOCK_JOB_READY", "data": {"device": "job0", "len": 21474836480, "offset": 21474836480, "speed": 0, "type": "mirror"}} +``` +5. Start migration on the source side: +``` +{ "execute": "migrate", "arguments": { "uri": "tcp:127.0.0.1:8091" } } +``` +6. Wait for the `pre-switchover` state of the migration: +``` +{ "execute": "query-migrate" } +{"return": {"expected-downtime": 300, "status": "pre-switchover", "setup-time": 3, "total-time": 11343, "ram": {"total": 8725020672, "postcopy-requests": 0, "dirty-sync-count": 2, "multifd-bytes": 0, "pages-per-second": 39550, "page-size": 4096, "remaining": 2871296, "mbps": 1073.7734399999999, "transferred": 963647065, "duplicate": 1899491, "dirty-pages-rate": 84, "skipped": 0, "normal-bytes": 944705536, "normal": 230641}}} +``` +7. Kill target QEMU to reproduce an issue. +8. Cancel the job on the source side: +``` +{ "execute": "block-job-cancel", "arguments": { "device": "job0" } } +``` + +Got the endless errror loop: +``` +... +{"timestamp": {"seconds": 1625586487, "microseconds": 413847}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413865}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413885}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +... +``` +Source qemu could be stopped only by using SIGKILL. diff --git a/results/classifier/gemma3:12b/hypervisor/467 b/results/classifier/gemma3:12b/hypervisor/467 new file mode 100644 index 00000000..bacf68ed --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/467 @@ -0,0 +1,2 @@ + +savevm/loadvm/migration broken for 32-bit arm guests that use TrustZone diff --git a/results/classifier/gemma3:12b/hypervisor/482 b/results/classifier/gemma3:12b/hypervisor/482 new file mode 100644 index 00000000..a7519779 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/482 @@ -0,0 +1,2 @@ + +Unable to set SVE VL to 1024 bits or above since 7b6a2198 diff --git a/results/classifier/gemma3:12b/hypervisor/492 b/results/classifier/gemma3:12b/hypervisor/492 new file mode 100644 index 00000000..44bfceaa --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/492 @@ -0,0 +1,28 @@ + +[git] "qemu-system-x86_64: Parameter 'drive' is missing" when I tried to launch an existing VM in Virt-Manager. +Description of problem: +This bug is related in some way to bug #488. + +I cannot start an existing virtual machine using qemu-git. +Additional information: +``` +internal error: process exited while connecting to monitor: 2021-07-19T19:24:27.044654Z qemu-system-x86_64: Parameter 'drive' is missing + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup + self._backend.create() + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1353, in create + raise libvirtError('virDomainCreate() failed') +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2021-07-19T19:24:27.044654Z qemu-system-x86_64: Parameter 'drive' is missing + +``` + +My last working build was made using commit 9bef7ea9. Using Peter Maydell commits as milestone, I noticed commit 9aef0954 was the first showing the bug. + +I'll try to do bisect between these two commits and report asap. There is about 40 commits to verify. diff --git a/results/classifier/gemma3:12b/hypervisor/496 b/results/classifier/gemma3:12b/hypervisor/496 new file mode 100644 index 00000000..c3338b91 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/496 @@ -0,0 +1,14 @@ + +qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed +Description of problem: +When I use qemu-system-aarch64 start a Debian(ARM64) on a mips64el host(ARM64 and X86_64 host don't have this bug), I get a bug as follows: + + +`qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed` + + +The crash code is in ../accel/tcg/cpu-exec.c:681, the code in qemu v5.2.0 as follows: + + +``` +# diff --git a/results/classifier/gemma3:12b/hypervisor/508 b/results/classifier/gemma3:12b/hypervisor/508 new file mode 100644 index 00000000..e4d34d26 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/508 @@ -0,0 +1,2 @@ + +x86_64 cmpxchg behavior in qemu tcg does not match the real CPU diff --git a/results/classifier/gemma3:12b/hypervisor/510 b/results/classifier/gemma3:12b/hypervisor/510 new file mode 100644 index 00000000..13f5f6e3 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/510 @@ -0,0 +1,2 @@ + +QEMU registers support on x64 diff --git a/results/classifier/gemma3:12b/hypervisor/518 b/results/classifier/gemma3:12b/hypervisor/518 new file mode 100644 index 00000000..fbd9cb33 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/518 @@ -0,0 +1,2 @@ + +Android for arm guest diff --git a/results/classifier/gemma3:12b/hypervisor/521202 b/results/classifier/gemma3:12b/hypervisor/521202 new file mode 100644 index 00000000..9b1e926f --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/521202 @@ -0,0 +1,8 @@ + +Windows XP x64 / 2008 Server x64 broken on 32-bit hosts with QEMU > 0.9.0 + +QEMU >0.9.0 fails to install/run 64-bit Windows XP guests on 32-bit hosts. This is mentioned here: http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=4625 . As explained there, 0.9.0 manages to install and run XP64 fine, if somewhat slowly. The host is an actual 32-bit CPU (Athlon XP), although I've tested it and confirmed the bug to occur on a Core2 Duo CPU running in 32-bit mode with KVM disabled. It's impossible to test with KVM enabled, as this causes Windows to detect a 32-bit CPU and refuse to run. + +When installing, the installer hangs at the "Setup is starting Windows" step. An attempt at running a converted VBox image reveals the problem lies somewhere in the ACPI -- in safe mode, the boot sequence gets to loading ACPI tables, then hangs indefinitely. Interestingly enough, the emulator itself runs fine, you can interact with the monitor etc., but the virtual CPU appears to stop; there's a marked point in "log cpu" output after which nothing comes. Disabling ACPI predictably does nothing to help, as in this case Windows refuses to run. + +I've tested with several versions, and 0.9.1 is the first one to break. The bug is still present in 0.11 and 0.12 as packaged by Ubuntu. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/551 b/results/classifier/gemma3:12b/hypervisor/551 new file mode 100644 index 00000000..5e251475 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/551 @@ -0,0 +1,2 @@ + +Null-ptr dereference in megasas_command_complete diff --git a/results/classifier/gemma3:12b/hypervisor/57 b/results/classifier/gemma3:12b/hypervisor/57 new file mode 100644 index 00000000..bc91142d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/57 @@ -0,0 +1,2 @@ + +IDE short PRDT abort diff --git a/results/classifier/gemma3:12b/hypervisor/585 b/results/classifier/gemma3:12b/hypervisor/585 new file mode 100644 index 00000000..d94ba0e9 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/585 @@ -0,0 +1,2 @@ + +mret trigger exception when pmp equals false diff --git a/results/classifier/gemma3:12b/hypervisor/588735 b/results/classifier/gemma3:12b/hypervisor/588735 new file mode 100644 index 00000000..db583118 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/588735 @@ -0,0 +1,20 @@ + +Quit command not working + +Qemu strace + + + +rt_sigreturn(0x1b) = 56 +clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6fddecbad0) = ? ERESTARTNOINTR (To be restarted) +--- SIGPROF (Profiling timer expired) @ 0 (0) --- +rt_sigreturn(0x1b) = 56 + + +started with : + +[root@virtual-test ~]# /root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -chardev socket,id=serial0,host=0.0.0.0,port=$CONSOLEPORT,telnet,server,nowait -serial chardev:serial0 -hda hda -hdb hdb -hdc hdc -hdd hdd -fda fd0 -fdb fd1 -chardev socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor chardev:monitor -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -M pc -m 4096 + +when removing -m 4096, the quit command works. + +but I think its a combination of different args that causes the problem. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/594 b/results/classifier/gemma3:12b/hypervisor/594 new file mode 100644 index 00000000..a0140d44 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/594 @@ -0,0 +1,2 @@ + +faults due to a amo instruction result in load faults instead of store/amo faults diff --git a/results/classifier/gemma3:12b/hypervisor/60 b/results/classifier/gemma3:12b/hypervisor/60 new file mode 100644 index 00000000..08afd4a1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/60 @@ -0,0 +1,2 @@ + +qemu-system-aarch64 (tcg): cval + voff overflow not handled, causes qemu to hang diff --git a/results/classifier/gemma3:12b/hypervisor/601 b/results/classifier/gemma3:12b/hypervisor/601 new file mode 100644 index 00000000..0bef3f73 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/601 @@ -0,0 +1,21 @@ + +import tensorflow causes qemu: uncaught target signal 6 (Aborted) - core dumped +Description of problem: +Crashes when importing tensorflow in Docker container under --platorm linux/amd64 on M1 Mac +``` +2021-09-06 13:35:24.435613: F tensorflow/core/lib/monitoring/sampler.cc:42] Check failed: bucket_limits_[i] > bucket_limits_[i - 1] (0 vs. 10) +qemu: uncaught target signal 6 (Aborted) - core dumped +``` +Steps to reproduce: +See https://gitlab.com/ryan-feather/docker-tensorflow-qemu-bug/ for Dockerfile and description of steps repeating here. +1. Using the dockerfile +``` +FROM python:3.9-buster +RUN pip install tensorflow==2.6.0 + +``` +2. `docker buildx build --iidfile build.id --platform linux/amd64 . --progress=plain` +3. ``` docker run --platform linux/amd64 `cat build.id` python -c "import tensorflow"``` +Additional information: +See +https://github.com/docker/for-mac/issues/5342 where the Docker team suggests this is a qemu bug. I couldn't find where anyone had opened one of these here, so hopefully this isn't a duplicate. diff --git a/results/classifier/gemma3:12b/hypervisor/607204 b/results/classifier/gemma3:12b/hypervisor/607204 new file mode 100644 index 00000000..f1f0429a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/607204 @@ -0,0 +1,34 @@ + +New qemu instances often cannot be started if host system is under load + +I've got a problem where I cannot start any new VMs with qemu-kvm if the host machine is under high CPU load. The problem is not 100% reproducible (it works sometimes), but under load conditions, it happens most of the time - roughly 95%. + +I'm usually using libvirt to start and stop KVM VMs. When using virsh to start a new VM under those conditions, the output looks like this: + +virsh # start testserver-a +error: Failed to start domain testserver-a +error: monitor socket did not show up.: Connection refused + +(There is a very long wait after the command has been sent until the error message shows up.) + +This is (an example of) the command line that libvirtd uses to start up qemu: + +----- snip ----- +LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.12 -enable-kvm -m 256 -smp 1,sockets=1,cores=1,threads=1 -name testserver-a -uuid 7cbb3665-4d58-86b8-ce8f-20541995a99c -nodefaults -chardev socket,id=monitor,path=/usr/local/var/lib/libvirt/qemu/testserver-a.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -no-acpi -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x7 -drive file=/data/testserver-a-system.img,if=none,id=drive-scsi0-0-1,boot=on -device scsi-disk,bus=scsi0.0,scsi-id=1,drive=drive-scsi0-0-1,id=scsi0-0-1 -drive file=/data/testserver-a-data1.img,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/data/testserver-a-data2.img,if=none,id=drive-virtio-disk2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk2,id=virtio-disk2 -drive file=/data/gentoo-install-amd64-minimal-20100408.iso,if=none,media=cdrom,id=drive-ide0-0-0,readonly=on -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/data/testserver-a_configfloppy.img,if=none,id=drive-fdc0-0-0 -global isa-fdc.driveA=drive-fdc0-0-0 -device e1000,vlan=0,id=net0,mac=52:54:00:84:6d:69,bus=pci.0,addr=0x6 -net tap,fd=24,vlan=0,name=hostnet0 -usb -vnc 127.0.0.1:1,password -k de -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 +----- snip ----- + +Copy-pasting this to a commandline on the host to start qemu manually leads to a non-functional qemu process that "just sits there" with nothing happening. The monitor socket /usr/local/var/lib/libvirt/qemu/testserver-a.monitor will, indeed, not show up. + +I've tried starting qemu with the same commandline but without the parameters for redirecting the monitor to a socket, without the fd parameter for the network interface and without the vnc parameter. This resulted in a black window with the title "QEMU (testserver-a) [Stopped]". I could not access the monitor console in graphical mode either. When I press Ctrl-Alt-2 in graphical mode to access the monitor console, qemu will sometimes (but not always) crash with a segfault about 2 seconds after. + +Some experimentation I've done suggests that this problem only happens if the high cpu load is caused by another qemu process, not if it is caused by something else running on the machine. + +The bug appears much less often if I leave off the -nodefaults parameter. + +The bug will still appear if I start qemu as qemu-system-x86_64 instead of qemu-kvm and replace the -enable-kvm parameter with -no-kvm. + +The host machine I'm running this on has got 16 cores in total. It looks like it is sufficient for this bug to surface if at least one of these cores is brought to near 100% use by a qemu process. + +The version of qemu I'm using is qemu-kvm 0.12.4, built from source. Libvirt is version 0.8.1, built from source as well. The host OS is Fedora 12. The Kernel version is 2.6.32.12-115.fc12.x86_64. + +Attached is an strace of attempting to start qemu which I hope will help someone with a better understanding of qemu's internals see what's actually going on there. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/609 b/results/classifier/gemma3:12b/hypervisor/609 new file mode 100644 index 00000000..77a46d26 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/609 @@ -0,0 +1,10 @@ + +Can't build system emulation with static on qemu 6.1 +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/623 b/results/classifier/gemma3:12b/hypervisor/623 new file mode 100644 index 00000000..c54982c4 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/623 @@ -0,0 +1,9 @@ + +Allow direct access to windows disks on hyper-V as well as virtiofsd, DAX +Additional information: +Depends on, first needs fixing of, Issue #346 / Issue #430 , Essentially accel=whpx is not working/is broken/has regression. +``` +J:\>E:\scoopg\shims\qemu-system-x86_64.exe --version +QEMU emulator version 6.1.0 (v6.1.0-11882-g7deea770bf-dirty) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +``` diff --git a/results/classifier/gemma3:12b/hypervisor/625 b/results/classifier/gemma3:12b/hypervisor/625 new file mode 100644 index 00000000..08053d30 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/625 @@ -0,0 +1,24 @@ + +qemu-hppa floating point POWER function is incorrect +Description of problem: +The floating point power function produces incorrect values, and possibly stack misshapes as well. +Steps to reproduce: +1. $ hppa1.1-unknown-linux-gnu-gcc pow.c -o pow -lm -static +2. $ qemu-hppa pow +3. the expected result is 10.0 ^ 6.0 = 6000000.0, instead of 403.45 +Additional information: +Example C source to reproduce, pow.c: +``` +#include <stdio.h> +#include <math.h> +int main() +{ + double base, expo, res; + base=10.0; + expo=6.0; + // res sould be 1e+6 + res = pow(base, expo); + printf("%.1lf^%.1lf = %.2lf\n", base, expo, res); + return 0; +} +``` diff --git a/results/classifier/gemma3:12b/hypervisor/628 b/results/classifier/gemma3:12b/hypervisor/628 new file mode 100644 index 00000000..80ff28af --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/628 @@ -0,0 +1,9 @@ + +nested virtualization on whpx +Additional information: +Depends on, first needs fixing of, Issue #346 / Issue #430 , Essentially accel=whpx is not working/is broken/has regression. +``` +PS J:\> E:\scoopg\shims\qemu-system-x86_64.exe --version +QEMU emulator version 6.1.0 (v6.1.0-11882-g7deea770bf-dirty) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +``` diff --git a/results/classifier/gemma3:12b/hypervisor/630 b/results/classifier/gemma3:12b/hypervisor/630 new file mode 100644 index 00000000..7171ce32 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/630 @@ -0,0 +1,2 @@ + +ubuntu-18.04-s390x-all job timeouts at 1h diff --git a/results/classifier/gemma3:12b/hypervisor/637 b/results/classifier/gemma3:12b/hypervisor/637 new file mode 100644 index 00000000..81ef0bb8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/637 @@ -0,0 +1,5 @@ + +qemu drive-mirror live migration sparse copy +Additional information: +Please reference this Proxmox post where the developers mention this feature not being available: +https://forum.proxmox.com/threads/migration-on-lvm-thin.50429/ diff --git a/results/classifier/gemma3:12b/hypervisor/645662 b/results/classifier/gemma3:12b/hypervisor/645662 new file mode 100644 index 00000000..e52b824c --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/645662 @@ -0,0 +1,41 @@ + +QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit + +When doing the regression tests for Python 3.1.2 with Qemu 0.12.5, (Linux version 2.6.26-2-686 (Debian 2.6.26-25lenny1)), +gcc (Debian 4.3.2-1.1) 4.3.2, Python compiled from sources within qemu, +3 math tests fail, apparently because the floating point unit is buggy. Qmeu was compiled from original sources +on Debian Lenny with kernel 2.6.34.6 from kernel.org, gcc (Debian 4.3.2-1.1) 4.3. + +Regression testing errors: + +test_cmath +test test_cmath failed -- Traceback (most recent call last): + File "/root/tools/python3/Python-3.1.2/Lib/test/test_cmath.py", line 364, in + self.fail(error_message) +AssertionError: acos0034: acos(complex(-1.0000000000000002, 0.0)) +Expected: complex(3.141592653589793, -2.1073424255447014e-08) +Received: complex(3.141592653589793, -2.1073424338879928e-08) +Received value insufficiently close to expected value. + + +test_float +test test_float failed -- Traceback (most recent call last): + File "/root/tools/python3/Python-3.1.2/Lib/test/test_float.py", line 479, in + self.assertEqual(s, repr(float(s))) +AssertionError: '8.72293771110361e+25' != '8.722937711103609e+25' + + +test_math +test test_math failed -- multiple errors occurred; run in verbose mode for deta + +=> + +runtests.sh -v test_math + +le01:~/tools/python3/Python-3.1.2# ./runtests.sh -v test_math +test_math BAD + 1 BAD + 0 GOOD + 0 SKIPPED + 1 total +le01:~/tools/python3/Python-3.1.2# \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/649 b/results/classifier/gemma3:12b/hypervisor/649 new file mode 100644 index 00000000..90a36810 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/649 @@ -0,0 +1,9 @@ + +qemu-6.1.0 causes I/O errors in VMs leading to data corruption +Description of problem: +after upgrading around 10 gentoo hosts from qemu-6.0.0-r53 to 6.1.0 most VMs (around 85 of 100, our VMs with PostgreSQL have 100% chance of hitting this) after some time (few minutes) will have I/O Errors, causing crashes and data corruption. +The VMs are stored on ZFS volumes. +Downgrading to qemu-6.0.0-r53 instantly fixes this. +Happens on completely different hardware (quad core Xeons to 32C Epyc2). + +Reproducible: Always diff --git a/results/classifier/gemma3:12b/hypervisor/658 b/results/classifier/gemma3:12b/hypervisor/658 new file mode 100644 index 00000000..5873a35a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/658 @@ -0,0 +1,2 @@ + +Missing documentation for TCG ctpop opcode diff --git a/results/classifier/gemma3:12b/hypervisor/664 b/results/classifier/gemma3:12b/hypervisor/664 new file mode 100644 index 00000000..dcb67192 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/664 @@ -0,0 +1,15 @@ + +hvf-accelerated x86_64 incorrectly reports virtual address bit width via CPUID +Description of problem: +When running qemu-system-x86_64 with hvf acceleration enabled the maximum extended cpuid function (available via EAX=0x80000000) is reported to be 0x80000001, which means that physical address and virtual address bit width (which is supposed to be reported via EAX=0x80000008) is not available. As per the intel IA32/64 manual: `Processors that do not support CPUID function 80000008H, support a linear-address width of 32.`, while in actuality qemu-system-x86_64 with hvf acceleration supports virtual addresses of up to 48 bit in width, like most modern x86_64 processors. +Steps to reproduce: +This can be observed when running SerenityOS on x86_64 qemu with hvf acceleration based on the following dmesg lines: +``` +[Kernel]: CPU[0]: Physical address bit width: 36 +[Kernel]: CPU[0]: Virtual address bit width: 32 +``` +But can also be reproduced by running the CPUID instruction with EAX set to 0x80000000 and observing that the returned value is 0x80000001. +Additional information: +The best way to resolve this as far as I can tell is to expose the 0x80000008 CPUID function and report the real values. + +NOTE: This is a report of the underlying bug that was found during the investigation of an issue raised in the SerenityOS repository, see https://github.com/SerenityOS/serenity/issues/10382 for more information. diff --git a/results/classifier/gemma3:12b/hypervisor/681 b/results/classifier/gemma3:12b/hypervisor/681 new file mode 100644 index 00000000..d283db35 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/681 @@ -0,0 +1,26 @@ + +Error saving memory to disk +Description of problem: +When trying to save the state of the machine using virt-manager (3.2.0) it fails with this error: + +Error saving domain: operation failed: domain save job: unexpectedly failed +```bash +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/vmmenu.py", line 182, in cb + vm.save(meter=asyncjob.get_meter()) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1377, in save + self._backend.managedSave(0) + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1780, in managedSave + raise libvirtError('virDomainManagedSave() failed') +libvirt.libvirtError: operation failed: domain save job: unexpectedly failed +``` +Steps to reproduce: +1. setup a virtual machine +2. setup a linux distro +3. try to save the memory to disk +Additional information: +Will be provided when needed diff --git a/results/classifier/gemma3:12b/hypervisor/685 b/results/classifier/gemma3:12b/hypervisor/685 new file mode 100644 index 00000000..8208a281 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/685 @@ -0,0 +1,70 @@ + +QEMU Segmentation fault - Xen / Ubuntu 18.04 +Description of problem: +See notes below. +Steps to reproduce: +See notes below. +Additional information: +* The error is very rare. +* The VMs have been created with `xl create` (Xen utility). +* The error has been found with _coredump_ ([core.qemu-system-i38.0.abb1047980ee4143937dcce7b8da9e60.16892.1634806267000000.lz4](/uploads/a90e21a2e14c9ebba07585034de25b1a/core.qemu-system-i38.0.abb1047980ee4143937dcce7b8da9e60.16892.1634806267000000.lz4)): +```bash +$ sudo coredumpctl info 16892 + PID: 16892 (qemu-system-i38) + UID: 0 (root) + GID: 0 (root) + Signal: 11 (SEGV) + Timestamp: Thu 2021-10-21 11:51:07 MSK (17min ago) + Command Line: /usr/bin/qemu-system-i386 -xen-domid 2679 -no-shutdown -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2679,server,nowait -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp + Executable: /usr/bin/qemu-system-i386 + Control Group: /system.slice/ptms.sandbox.sandbox-creator.service + Unit: ptms.sandbox.sandbox-creator.service + Slice: system.slice + Boot ID: abb1047980ee4143937dcce7b8da9e60 + Machine ID: bdce82649a9d4d9db192a692b330943f + Hostname: ptms-7 + Storage: /var/lib/systemd/coredump/core.qemu-system-i38.0.abb1047980ee4143937dcce7b8da9e60.16892.1634806267000000.lz4 + Message: Process 16892 (qemu-system-i38) of user 0 dumped core. + + Stack trace of thread 16892: + #0 0x00007f1c6d33ca5f __memmove_avx_unaligned_erms (libc.so.6) + #1 0x00005586abeae8bf iov_from_buf_full (qemu-system-i386) + #2 0x00005586abe03d46 n/a (qemu-system-i386) + #3 0x00005586abdd17ad n/a (qemu-system-i386) + #4 0x00005586abeac93c n/a (qemu-system-i386) + #5 0x00007f1c6d2067b0 n/a (libc.so.6) + #6 0x00005586abeb89bd n/a (qemu-system-i386) + #7 0x00005586abeaaf87 aio_bh_poll (qemu-system-i386) + #8 0x00005586abe9a45e aio_dispatch (qemu-system-i386) + #9 0x00005586abeaad9e n/a (qemu-system-i386) + #10 0x00007f1c6fd7f537 g_main_context_dispatch (libglib-2.0.so.0) + #11 0x00005586abeb5caa main_loop_wait (qemu-system-i386) + #12 0x00005586abca092d qemu_main_loop (qemu-system-i386) + #13 0x00005586ab9f508e main (qemu-system-i386) + #14 0x00007f1c6d1cfbf7 __libc_start_main (libc.so.6) + #15 0x00005586ab9f97fa _start (qemu-system-i386) + + Stack trace of thread 16932: + #0 0x00007f1c6d2c9639 syscall (libc.so.6) + #1 0x00005586abe9de1b qemu_event_wait (qemu-system-i386) + #2 0x00005586abea5e28 n/a (qemu-system-i386) + #3 0x00005586abe9d0b6 n/a (qemu-system-i386) + #4 0x00007f1c6d5a66db start_thread (libpthread.so.0) + #5 0x00007f1c6d2cf71f __clone (libc.so.6) + + Stack trace of thread 16957: + #0 0x00007f1c6d5b0474 __libc_read (libpthread.so.0) + #1 0x00007f1c71f67777 n/a (libxenstore.so.3.0) + #2 0x00007f1c71f6784d n/a (libxenstore.so.3.0) + #3 0x00007f1c71f67b61 n/a (libxenstore.so.3.0) + #4 0x00007f1c6d5a66db start_thread (libpthread.so.0) + #5 0x00007f1c6d2cf71f __clone (libc.so.6) + + Stack trace of thread 16958: + #0 0x00007f1c6d5b0474 __libc_read (libpthread.so.0) + #1 0x00007f1c71f67777 n/a (libxenstore.so.3.0) + #2 0x00007f1c71f6784d n/a (libxenstore.so.3.0) + #3 0x00007f1c71f67b61 n/a (libxenstore.so.3.0) + #4 0x00007f1c6d5a66db start_thread (libpthread.so.0) + #5 0x00007f1c6d2cf71f __clone (libc.so.6) +``` diff --git a/results/classifier/gemma3:12b/hypervisor/686 b/results/classifier/gemma3:12b/hypervisor/686 new file mode 100644 index 00000000..dc498350 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/686 @@ -0,0 +1,40 @@ + +Qemu crashes if it is paused and migrated twice +Description of problem: +If the vm is in PAUSED state (in Openstack parlance) (I think libvirt calls that paused as well but uses the command `virsh suspend`), and live-migrated twice, the second time the Qemu process terminates. + +This is perfectly repeatable. + +If the VM is unpaused and re-paused after the first migration, then the problem does not occur on the next migration. +Steps to reproduce: +See also the referenced bug report to openstack, above. +1. `$ openstack stack create ....` +2. `$ openstack server pause <UUID>` +(wait until done) +3. `$ openstack server migrate --live-migration <UUID>` +(wait until done) +4. `$ openstack server migrate --live-migration <UUID>` + +The VM is now in ERROR state because it has disappeared: `libvirt.libvirtError: Domain not found: no domain with matching uuid '<UUID>'` +Additional information: +The last few lines from the instance-00000ba2.log seem pertinent (this is from the receiving Qemu instance): +``` +2021-10-22 15:32:53.829+0000: initiating migration +qemu-system-x86_64: /build/qemu-lb4V37/qemu-4.2/block.c:5523: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +2021-10-22 15:32:59.122+0000: shutting down, reason=crashed +``` +This is logged by libvirt (also on the receiving side): +``` +Oct 22 15:29:04 ybk140931 ovs-vsctl[20174]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port tap3a71aa63-6a +Oct 22 15:31:31 ybk140931 ovs-vsctl[21412]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port tap3a71aa63-6a -- add-port br-int tap3a71aa63-6a -- set Interface tap3a71aa63-6a "external-ids:attached-mac=\"fa:16:3e:da:03:56\"" -- set Interface tap3a71aa63-6a "external-ids:iface-id=\"3a71aa63-6a39-41d8-9602-04b84834db9e\"" -- set Interface tap3a71aa63-6a "external-ids:vm-id=\"de2b27d2-345c-45fc-8f37-2fa0ed1a1151\"" -- set Interface tap3a71aa63-6a external-ids:iface-status=active +Oct 22 15:32:58 ybk140931 libvirtd[3237]: Unable to read from monitor: Connection reset by peer +Oct 22 15:32:59 ybk140931 ovs-vsctl[22001]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port tap3a71aa63-6a +Oct 22 15:32:59 ybk140931 libvirtd[3237]: operation failed: domain is not running +Oct 22 15:32:59 ybk140931 libvirtd[3237]: internal error: qemu unexpectedly closed the monitor: 2021-10-22T15:32:58.845667Z qemu-system-x86_64: Failed to load virtio_pci/modern_queue_state:used + 2021-10-22T15:32:58.845687Z qemu-system-x86_64: Failed to load virtio_pci/modern_state:vqs + 2021-10-22T15:32:58.845690Z qemu-system-x86_64: Failed to load virtio/extra_state:extra_state + 2021-10-22T15:32:58.845692Z qemu-system-x86_64: Failed to load virtio-rng:virtio + 2021-10-22T15:32:58.845695Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:06.0/virtio-rng' + 2021-10-22T15:32:58.847860Z qemu-system-x86_64: load of migration failed: Input/output error +Oct 22 15:32:59 ybk140931 libvirtd[3237]: operation failed: domain 'instance-00000ba2' is not running +``` diff --git a/results/classifier/gemma3:12b/hypervisor/687 b/results/classifier/gemma3:12b/hypervisor/687 new file mode 100644 index 00000000..593309bc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/687 @@ -0,0 +1,2 @@ + +what is the DMAR? diff --git a/results/classifier/gemma3:12b/hypervisor/692 b/results/classifier/gemma3:12b/hypervisor/692 new file mode 100644 index 00000000..c0cace27 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/692 @@ -0,0 +1,2 @@ + +remove_fd_in_watch does not call g_source_unref diff --git a/results/classifier/gemma3:12b/hypervisor/692570 b/results/classifier/gemma3:12b/hypervisor/692570 new file mode 100644 index 00000000..75f59930 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/692570 @@ -0,0 +1,109 @@ + +APIC Latency causing BSOD. + +I have a Proxmox Server with the following specs: + +Version: + +pve-manager: 1.7-10 (pve-manager/1.7/5323) +running kernel: 2.6.32-4-pve +proxmox-ve-2.6.32: 1.7-28 +pve-kernel-2.6.32-4-pve: 2.6.32-28 +qemu-server: 1.1-25 +pve-firmware: 1.0-9 +libpve-storage-perl: 1.0-16 +vncterm: 0.9-2 +vzctl: 3.0.24-1pve4 +vzdump: 1.2-9 +vzprocps: 2.0.11-1dso2 +vzquota: 3.0.11-1 +pve-qemu-kvm: 0.13.0-2 +ksm-control-daemon: 1.0-4 + +VM Configuration: + +name: TS64 +ide2: none,media=cdrom +bootdisk: ide0 +ostype: w2k3 +ide0: data:vm-104-disk-1 +memory: 10240 +sockets: 1 +vlan0: virtio=C6:4C:B3:BB:AD:67 +onboot: 1 +cores: 4 +boot: cad +freeze: 0 +cpuunits: 1000 +acpi: 1 +kvm: 1 + +CPU 2x Xeon Quad Core E5620 2.4GHZ Processors: + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 44 +model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz +stepping : 2 +cpu MHz : 2400.323 +cache size : 12288 KB +physical id : 0 +siblings : 8 +core id : 9 +cpu cores : 4 +apicid : 19 +initial apicid : 19 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid +bogomips : 4800.19 +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: + +Performance: + +CPU BOGOMIPS: 76803.21 +REGEX/SECOND: 850066 +HD SIZE: 33.96 GB (/dev/mapper/pve-root) +BUFFERED READS: 333.03 MB/sec +AVERAGE SEEK TIME: 6.10 ms +FSYNCS/SECOND: 2948.85 +DNS EXT: 131.42 ms +DNS INT: 1.28 ms + +I've been successfully running 2 Windows 2003 32-Bit Standard Edition Servers on this server for over a month now. Both were migrations from actual physical servers. However, I've continued to receive random crashes on a Windows 2003 64-bit standard edition running terminal services, which was a fresh install. The server runs fine for hours under a decent load (20 users) and then will crash with a 3B bug check code (System_Service_Exception). I opened a ticket with Microsoft and submitted multiple memory dumps and their engineers suggested the following: + +Dump Analyses Result: +=================== + +What happened is that the OS initiated an APIC /software interrupt. This is handled by the APIC in real hardware. In your Virtual Environment case where you are using Linux based VM – Proxmox, the VM implementation somehow has to make it happen on a virtual machine with the same latency in the virtual APIC. The problem is that there is a latency between when it was initiated and when it happened. + + +Below are the details for understanding the process or concept of APIC interrupts: + +What the Local APIC Is +The Local APIC (LAPIC) is a circuit that is part of the CPU chip. It contains these basic elements: +A mechanism for generating +1. interrupts +2. A mechanism for accepting interrupts +3. A timer + +If you have a multiprocessor system, the APIC's are wired together so they can communicate. So the LAPIC on CPU 0 can communicate with the LAPIC on CPU 1, etc. + + +What the IO APIC Is + +This is a separate chip that is wired to the Local APIC's so it can forward interrupts on to the CPU chips. It is programmed similar to the 8259's but has more flexibility. +It is wired to the same bus as the Local APIC's so it can communicate with them. + +Note:- In our scenario, it’s all Virtualized interrupts or calls because of hypervisor in picture and thus we need to contact the VM application vendor to get a check of this latency issue in APIC interrupt. +------------------------------------------------End of Message---------------------------------- + + + +Their engineers are saying that there is a latency issue with APIC. I'm not exactly sure how this can be corrected. Is this a known issue and is their a solution to this problem. I love Proxmox, but my main reason for using it was to upgrade my terminal server to better hardware, while leveraging it for other virtual machines as well. The forum administrator for Proxmox, suggested I bring this issue to your attention. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/697 b/results/classifier/gemma3:12b/hypervisor/697 new file mode 100644 index 00000000..dfa83e89 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/697 @@ -0,0 +1,2 @@ + +linux-user create default CPU type before parsing the ELF header for specific CPU type diff --git a/results/classifier/gemma3:12b/hypervisor/699 b/results/classifier/gemma3:12b/hypervisor/699 new file mode 100644 index 00000000..a4fefaef --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/699 @@ -0,0 +1,2 @@ + +SGX QEMU release diff --git a/results/classifier/gemma3:12b/hypervisor/703 b/results/classifier/gemma3:12b/hypervisor/703 new file mode 100644 index 00000000..2beed929 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/703 @@ -0,0 +1,18 @@ + +Resizable BAR (ReBAR) support on VFIO +Additional information: +Currently `vfio_add_ext_cap()` doesn't pass ReBAR support option to VFIO. + +There was a report that removing the line you see below makes it boot, but the system is not stable. +Needs investigation. + +[https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089](https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089) +``` switch (cap_id) { + case 0: /* kernel masked capability */ + case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */ + case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization */ + case PCI_EXT_CAP_ID_REBAR: /* Can't expose read-only */ + trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, next); +``` + +[Discussion link](https://forum.level1techs.com/t/smart-access-memory-vs-qemu-kvm/169447) diff --git a/results/classifier/gemma3:12b/hypervisor/707 b/results/classifier/gemma3:12b/hypervisor/707 new file mode 100644 index 00000000..9a1ce823 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/707 @@ -0,0 +1,63 @@ + +The QEMU emulator incorrectly interprets the contents of the SLIC table. See attached image. +Description of problem: +The QEMU emulator incorrectly interprets the contents of the SLIC table. + +The SLIC table read on pure hardware and in a virtual machine in the fedora 34 and 35: + + +Steps to reproduce: +Steps to Reproduce: + +1. Install Fedora 34 + +2. Install virtualization group: + + dnf group install virtualization + +4. Place SLIC binary image(slic.bin) into the direcrory /var/lib/libvirt/images + +3. Create Virtual Machine with Virtual Machine Manager. + +4. Modify xml description of virtual machine: + `... + <os> + ... + <acpi> + <table type='slic'>/var/lib/libvirt/images/slic.bin</table> + </acpi> + </os> + ...` + +5. Install Microsoft Windows 7 64-bit into Virtual machine. + +6. Place sertificate into Windows 7. + +7. Run with admin rights: + + slmgr.vbs /ilc <sertificate> + slmgr.vbs /ipk <key> + +8. Windows 7 will be activated ! + +9. Save Virtual Machine Image and it's xml description anywere. + +10. Install Fedora 35 + +11. Install virtualization group. + +12. Place saved Virtual Machine Image and slic.bin into the directory /var/lib/libvirt/images/ + +13. Register virtual machine: + + virsh -c qemu:///system define <xml_file> + +15. Run virtual machine - Windows 7 will lose it activation. +Additional information: +Fedora 34 has: + kernel-5.14.15-200.fc34.x86_64, qemu-system-x86-5.2.0-8.fc34.x86_64 + +Fedora 35 has: + kernel-5.14.15-300.fc35.x86_64, qemu-system-x86-6.1.0-9.fc35.x86_64 + +Slick Binary Image: [slic.bin](/uploads/da94a96516c3dbe52803fb84738f434c/slic.bin) diff --git a/results/classifier/gemma3:12b/hypervisor/720657 b/results/classifier/gemma3:12b/hypervisor/720657 new file mode 100644 index 00000000..7b904f0d --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/720657 @@ -0,0 +1,25 @@ + +SVM intercept for VINTR exits too early + +The following happens with QEMU-0.14-rc2. QEMU-0.13 did not have this problem. + +A guest operating system running inside an SVM VM contains the following code sequence: +c000002b: fb sti +c000002c: 0f 35 sysexit + +The following is a list of exits that occur at guest RIP 0xc000002c (other exits omitted for clarity): + +exit=0x60 int_shadow=0x1 int_control=0x1000000 inj=0x600000000 rip=0xc000002c +entry: int_shadow=0x1 int_control=0x1000000 inj=0x600000000 + +(exit due to physical interrupt, correctly reports STI blocking, entry does not inject anything) + +exit=0x60 int_shadow=0x1 int_control=0x1000000 inj=0x600000000 rip=0xc000002c +entry: int_shadow=0x1 int_control=0x1100100 inj=0x600000000 + +(exit due to physical interrupt, correctly reports STI blocking, entry pends a VINTR to cause a VM exit when interrupt window opens. VINTR is being intercepted by the hypervisor.) + +exit=0x64 int_shadow=0x0 int_control=0x1100100 inj=0x600000000 rip=0xc000002c +entry: int_shadow=0x0 int_control=0x1000000 inj=0x6800000a0 + +(exit due to VINTR. At this point STI blocking is still effective - though not reported. Actually, the VINTR exit should occur AFTER the SYSEXIT instruction, not after STI. Due to this bug, the hypervisor injects vector 0xa0 into an interrupt shadow, and things break). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/732 b/results/classifier/gemma3:12b/hypervisor/732 new file mode 100644 index 00000000..ddaad066 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/732 @@ -0,0 +1,2 @@ + +Can not use --enable-fuzzing on Ubuntu 20.04 Aarch64 diff --git a/results/classifier/gemma3:12b/hypervisor/737 b/results/classifier/gemma3:12b/hypervisor/737 new file mode 100644 index 00000000..6e3089a0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/737 @@ -0,0 +1,4 @@ + +s390x/tcg: Implement Miscellaneous-Instruction-Extensions Facility 3 for the s390x +Additional information: +http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf diff --git a/results/classifier/gemma3:12b/hypervisor/738 b/results/classifier/gemma3:12b/hypervisor/738 new file mode 100644 index 00000000..1323e661 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/738 @@ -0,0 +1,4 @@ + +s390x/tcg: Implement Vector-Enhancements Facility 2 for s390x +Additional information: +http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf diff --git a/results/classifier/gemma3:12b/hypervisor/742 b/results/classifier/gemma3:12b/hypervisor/742 new file mode 100644 index 00000000..102dfab6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/742 @@ -0,0 +1,45 @@ + +Cache Layout wrong on many Zen Arch CPUs +Description of problem: +This is `coreinfo -l` when running Windows as host: + + + +This is `coreinfo -l` when running the same Windows as guest with 6 cores and 6 threads (half of each): + + +Steps to reproduce: +1. You need a AMD Ryzen 3900X. It has an L3 cache over 3 cores +2. Use `-cpu host,+topoext,host-cache-info=on` +3. Use `coreinfo -l` to see how the L3 cache is distributed +Additional information: +1. When running without `host-cache-info=on` then the L3 cache is spread on all the cpus. +2. `lscpu -e`: + +``` +CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ + 0 0 0 0 0:0:0:0 yes 4672.0698 2200.0000 3800.000 + 1 0 0 1 1:1:1:0 yes 4672.0698 2200.0000 3800.000 + 2 0 0 2 2:2:2:0 yes 4672.0698 2200.0000 3800.000 + 3 0 0 3 4:4:4:1 yes 4672.0698 2200.0000 3800.000 + 4 0 0 4 5:5:5:1 yes 4672.0698 2200.0000 3800.000 + 5 0 0 5 6:6:6:1 yes 4672.0698 2200.0000 3800.000 + 6 0 0 6 8:8:8:2 yes 4672.0698 2200.0000 3800.000 + 7 0 0 7 9:9:9:2 yes 4672.0698 2200.0000 3610.580 + 8 0 0 8 10:10:10:2 yes 4672.0698 2200.0000 3800.000 + 9 0 0 9 12:12:12:3 yes 4672.0698 2200.0000 3800.000 + 10 0 0 10 13:13:13:3 yes 4672.0698 2200.0000 3800.000 + 11 0 0 11 14:14:14:3 yes 4672.0698 2200.0000 3800.000 + 12 0 0 0 0:0:0:0 yes 4672.0698 2200.0000 3800.000 + 13 0 0 1 1:1:1:0 yes 4672.0698 2200.0000 3800.000 + 14 0 0 2 2:2:2:0 yes 4672.0698 2200.0000 3800.000 + 15 0 0 3 4:4:4:1 yes 4672.0698 2200.0000 3800.000 + 16 0 0 4 5:5:5:1 yes 4672.0698 2200.0000 3800.000 + 17 0 0 5 6:6:6:1 yes 4672.0698 2200.0000 3800.000 + 18 0 0 6 8:8:8:2 yes 4672.0698 2200.0000 3800.000 + 19 0 0 7 9:9:9:2 yes 4672.0698 2200.0000 3800.000 + 20 0 0 8 10:10:10:2 yes 4672.0698 2200.0000 3800.000 + 21 0 0 9 12:12:12:3 yes 4672.0698 2200.0000 3800.000 + 22 0 0 10 13:13:13:3 yes 4672.0698 2200.0000 3800.000 + 23 0 0 11 14:14:14:3 yes 4672.0698 2200.0000 3800.000 +``` diff --git a/results/classifier/gemma3:12b/hypervisor/743 b/results/classifier/gemma3:12b/hypervisor/743 new file mode 100644 index 00000000..2b947aa8 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/743 @@ -0,0 +1,12 @@ + +aarch64: Number of SMP CPUS exceeds max CPUs supported by machine (10 > 8) for M1 Pro/Max +Description of problem: +Trying to launch QEMU with more than 8 cores gives the following error: + +`qemu-system-aarch64: Number of SMP CPUs requested (10) exceeds max CPUs supported by machine 'mach-virt' (8)` + +Apple M1 Pro can have up to 10 cores while M1 Max only has 10 cores. +Steps to reproduce: +1. Install QEMU via homebrew (or MacPorts or from source) +2. Run `qemu-system-aarch64 -machine virt,highmem=off -accel hvf -cpu cortex-a72 -smp 10` +3. Get error, QEMU doesn't start diff --git a/results/classifier/gemma3:12b/hypervisor/747 b/results/classifier/gemma3:12b/hypervisor/747 new file mode 100644 index 00000000..a394c1f7 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/747 @@ -0,0 +1,31 @@ + +hvf-accelerated aarch64 hangs when switching to big endian mode +Description of problem: +Trying to boot a big endian Linux kernel using the above command line on an M1 Mac Mini just hangs, there is not a single output. However, by replacing `hvf` with `tcg`, the kernel boots up fine. The kernel also starts if I use KVM acceleration on a Linux host system. +Steps to reproduce: +1. Build a Linux kernel for big endian arm64 +2. Try to boot it with -accel hvf on an M1 Mac +3. Observe a lot of nothing happening :-) +Additional information: +Sample run, TCG vs HVF +``` +mikan:/tmp% qemu-system-aarch64 -accel tcg -machine virt,highmem=off -cpu cortex-a72 -nographic -kernel /tmp/vmlinuz-5.10.76-gentoo-r1-arm64.be |& head -16 +[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083] +[ 0.000000] Linux version 5.10.76-gentoo-r1-arm64 (root@localhost) (aarch64-unknown-linux-gnu-gcc (Gentoo 11.2.0 p1) 11.2.0, GNU ld (Gentoo 2.37_p1 p0) 2.37) #1 SMP Sun Nov 21 16:30:21 -00 2021 +[ 0.000000] Machine model: linux,dummy-virt +[ 0.000000] NUMA: No NUMA configuration found +[ 0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x0000000047ffffff] +[ 0.000000] NUMA: NODE_DATA [mem 0x47f65300-0x47f76fff] +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000040000000-0x0000000047ffffff] +[ 0.000000] DMA32 empty +[ 0.000000] Normal empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000040000000-0x0000000047ffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x0000000047ffffff] +[ 0.000000] psci: probing for conduit method from DT. +[ 0.000000] psci: PSCIv0.2 detected in firmware. +mikan:/tmp% qemu-system-aarch64 -accel hvf -machine virt,highmem=off -cpu cortex-a72 -nographic -kernel /tmp/vmlinuz-5.10.76-gentoo-r1-arm64.be +``` +(followed by tumbleweeds) diff --git a/results/classifier/gemma3:12b/hypervisor/750 b/results/classifier/gemma3:12b/hypervisor/750 new file mode 100644 index 00000000..4901c48e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/750 @@ -0,0 +1,34 @@ + +/proc/cpuinfo doesn't present guest cpuinfo for most architectures (including M1 Macs) +Description of problem: +I tried to start Blender inside an amd docker container, emulated on M1 Mac, running noVNC to access the the GUI via Chrome. +From Blender versions 2.8 and higher I get the following error message: + +``` + ArchError: Could not find 'cpu MHz' in /proc/cpuinfo + Function: Arch_InitTickTimer + File: /home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/build/usd/src/external_usd/pxr/base/arch/timing.cpp + Line: 133 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +``` + +I posted the problem to Blender [here](https://developer.blender.org/T92956) as well as to docker [here](https://github.com/docker/for-mac/issues/6047). +Steps to reproduce: +You need: +- ✅ M1 Mac +- ✅ Docker Desktop 4.1.1 (69879) + +Setup the Container: + +1. Unzip the attached file +2. In a terminal go to the unzipped folder +3. run `source build-and-launch.sh` to build the image and spin up a container +4. open a browser and go to [http://localhost:6901](http://localhost:6901) +5. login using password `pass` +6. see the README.txt on the Desktop you just logged into +7. == Follow the README instructions == + + + +[blender-bug-report-202111091146.zip](/uploads/340ada45a9ee0585cfc0cdfcc1932fb4/blender-bug-report-202111091146.zip) diff --git a/results/classifier/gemma3:12b/hypervisor/775 b/results/classifier/gemma3:12b/hypervisor/775 new file mode 100644 index 00000000..7b8e995a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/775 @@ -0,0 +1,5 @@ + +Backup always use Microsoft VSS-FULL Option and breaks other Backups +Additional information: +MS VSS-Options +[https://docs.microsoft.com/en-us/windows/win32/api/vss/ne-vss-vss_backup_type](https://docs.microsoft.com/en-us/windows/win32/api/vss/ne-vss-vss_backup_type) diff --git a/results/classifier/gemma3:12b/hypervisor/780 b/results/classifier/gemma3:12b/hypervisor/780 new file mode 100644 index 00000000..16d60974 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/780 @@ -0,0 +1,55 @@ + +qemu-system-x86_64: qemu dead-lock when mirror job exit and vm stop in a race +Description of problem: +machine under continuous pressure, at the end of the migration phase. +Libvirtd construction exception at the same time. +In mirror_run, mirror_write_complete set s->ret to negative value and exit mirror_run; Job_co_entry throws the bh of job_exit into the main thread; + +While the live_migration thread gets the qemu_global_mutex, and set to main thread by blk_set_aio_context; when it just polles the bh of job_exit, and run to bdrv_flush. So there need the main thread to process bdrv_flush_co_entry, then we can exit bdrv_flush. +If the main thread is waiting the qemu_mutex_lock_iothread_impl, bdrv_flush_co_entry cannot be executed, and the Live_migration thread cannot exit to release qemu_global_mutex, resulting in deadlock +Steps to reproduce: +1.migrate the machine and let machine under continuous pressure; +2.gdb to qemu and make break point to virtio_blk_data_plane_stop; +3.when hit virtio_blk_data_plane_stop, kill libvirtd; +4.let live_migration thread to poll job_exit +Additional information: +``` +#0 0x00007f8f662d12f2 in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:112 +#1 0x00007f8f662d58ae in aio_poll (ctx=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736 +#2 0x00007f8f6530bcca in bdrv_flush (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block/io.c:2778 +#3 0x00007f8f65345143 in bdrv_close (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block.c:4073 +#4 0x00007f8f65345373 in bdrv_delete (bs=0x5580c5857b30) at /usr/src/qemu/block.c:4335 +#5 0x00007f8f65345405 in bdrv_unref (bs=<optimized out>) at /usr/src/qemu/block.c:5676 +#6 0x00007f8f65344d95 in bdrv_root_unref_child (child=<optimized out>) at /usr/src/qemu/block.c:2516 +#7 0x00007f8f65353f56 in block_job_remove_all_bdrv (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/blockjob.c:203 +#8 0x00007f8f65317b87 in mirror_exit_common (job=0x5580c6d55cc0) at /usr/src/qemu/block/mirror.c:776 +#9 0x00007f8f65317cc8 in mirror_abort (job=<optimized out>) at /usr/src/qemu/block/mirror.c:804 +#10 0x00007f8f6632737b in job_finalize_single (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/job.c:680 +#11 0x00007f8f66327d70 in job_completed_txn_abort (job=<optimized out>) at /usr/src/qemu/job.c:758 +#12 0x00007f8f66328018 in job_exit (opaque=0x5580c6d55cc0) at /usr/src/qemu/job.c:873 +#13 0x00007f8f662d130f in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:118 +#14 0x00007f8f662d5716 in aio_poll (ctx=ctx@entry=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736 +#15 0x00007f8f662e6b4d in aio_wait_bh_oneshot (ctx=0x5580c53a5c60, cb=<optimized out>, opaque=<optimized out>) at /usr/src/qemu/util/aio-wait.c:71 +#16 0x00007f8f65340978 in bdrv_attach_aio_context (bs=bs@entry=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60) at /usr/src/qemu/block.c:5985 +#17 0x00007f8f65345fd5 in bdrv_set_aio_context_ignore (bs=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6050 +#18 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=0x5580c5857b30, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032 +#19 0x00007f8f65353bd4 in child_job_set_aio_ctx (c=<optimized out>, ctx=0x5580c53a5c60, ignore=0x7f8eb8ff8c20) at /usr/src/qemu/blockjob.c:172 +#20 0x00007f8f6534604b in bdrv_set_aio_context_ignore (bs=0x5580c53c46c0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6040 +#21 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=bs@entry=0x5580c5978290, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032 +#22 0x00007f8f653462b8 in bdrv_child_try_set_aio_context (bs=bs@entry=0x5580c5978290, ctx=ctx@entry=0x5580c53a5c60, ignore_child=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block.c:6145 +#23 0x00007f8f653029aa in blk_do_set_aio_context (blk=0x5580c53c42b0, new_context=0x5580c53a5c60, update_root_node=update_root_node@entry=true, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1948 +#24 0x00007f8f65304b0d in blk_set_aio_context (blk=<optimized out>, new_context=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1980 +#25 0x00007f8f64f07976 in virtio_blk_data_plane_stop (vdev=0x5580c6d8a510) at /usr/src/qemu/hw/block/dataplane/virtio-blk.c:305 +#26 0x00007f8f64f7be83 in virtio_bus_stop_ioeventfd (bus=0x5580c6d8a498) at /usr/src/qemu/hw/virtio/virtio-bus.c:247 +#27 0x00007f8f64f77e8b in virtio_vmstate_change (opaque=0x5580c6d8a510, running=0, state=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/hw/virtio/virtio.c:2423 +#28 0x00007f8f663563f5 in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/huawei/microvm/microvm-platform.c:196 +#29 0x00007f8f66335af9 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE, send_stop=send_stop@entry=true) at /usr/src/qemu/cpus.c:1130 +#30 0x00007f8f66335dd1 in vm_stop (state=<optimized out>) at /usr/src/qemu/cpus.c:2207 +#31 0x00007f8f66335f7e in vm_stop_force_state (state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/cpus.c:2267 +#32 0x00007f8f65197cfc in migration_try_vm_stop_and_save_concurrent (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:2976 +#33 0x00007f8f6519c627 in migration_completion (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3039 +#34 0x00007f8f6519cc8b in migration_iteration_run (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3571 +#35 0x00007f8f6519d190 in migration_thread (opaque=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3801 +#36 0x00007f8f662d82e0 in qemu_thread_start (args=0x5580c57d0300) at /usr/src/qemu/util/qemu-thread-posix.c:519 +#37 0x00007f8f6648bf3b in start_thread (arg=0x7f8eb8ff9700) at pthread_create.c:486 +``` diff --git a/results/classifier/gemma3:12b/hypervisor/788 b/results/classifier/gemma3:12b/hypervisor/788 new file mode 100644 index 00000000..b08209d1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/788 @@ -0,0 +1,2 @@ + +FEAT_PAuth trapping behaviour incorrectly emulated on Secure-EL0/1 with Secure-EL2 disabled diff --git a/results/classifier/gemma3:12b/hypervisor/789 b/results/classifier/gemma3:12b/hypervisor/789 new file mode 100644 index 00000000..cac79b57 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/789 @@ -0,0 +1,13 @@ + +QEMU arm (not arm64) crashes on apple silicon when run via docker desktop +Description of problem: +docker build of the simple Dockerfile here causes QEMU to crash in arm +emulation. It is perfectly reproducible. + +FROM balenalib/rpi-raspbian:bullseye-20210925 + +USER root + +RUN apt-get update -y && apt-get upgrade -y +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/791 b/results/classifier/gemma3:12b/hypervisor/791 new file mode 100644 index 00000000..b1f38eed --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/791 @@ -0,0 +1,2 @@ + +unable to execute QEMU command - SGX VM using libvirtd diff --git a/results/classifier/gemma3:12b/hypervisor/844 b/results/classifier/gemma3:12b/hypervisor/844 new file mode 100644 index 00000000..5235eebc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/844 @@ -0,0 +1,45 @@ + +Close gap for x86_64-v3 ABI in TCG - CPU support for fma, f16c, avx, avx2 features required +Description of problem: +There are 3 additional ABIs defined by a collaboration of vendors for the `x86_64` architecture, over the original baseline: + +* https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex + +This is no problem for KVM assuming suitable host hardware, but TCG is currently unable to support more than the original baseline and the `x86_64-v2` step. + +For `x86_64-v3` there are some gaps in its emulation coverage. This can be seen by taking `Nehalem` which is a good fit for `x86_64-v2`, and requesting the extra v3 features: + +``` +$ qemu-system-x86_64 -accel tcg -cpu Nehalem,+avx,+avx2,+bmi1,+bmi2,+f16c,+fma,+abm,+movbe +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +``` + +IOW, the strict bare minimum TCG needs in order to satisfy `x86_64-v3` is `fma`, `f16c`, `avx` and `avx2` support + +If we want to fully support a named CPU model satisfying v3, then `Haswell` is the closest and that has a few additional gaps + +``` +$ qemu-system-x86_64 -accel tcg -cpu Haswell-noTSX +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] + +``` + +Those additional gaps wouldn't impact ability to execute binaries build for the `x86_64-v3` ABI though, so not as important. + +The reason `x86_64-v3` compatibility in TCG matters is because sooner or later some Linux OS are going to set this as the baseline for their compiler toolchain. There is a proposal to set this in `Fedora ELN`, which is what feeds in to a possible future `RHEL-10`. + +I imagine adding these extra features would be non-negligible work in TCG / take some time to complete. + +Thus I file this bug for the purpose of suggesting these 4 specific missing features be considered a priority to address, compared to other missing CPU features in TCG that might be considered more of a 'nice to have'. + +eg looking further the `x86_64-v4` baseline brings in a requirement for `avx512f`, `avx512bw`, `avx512cd`, `avx512dq`, `avx512vl` which TCG also lacks, but I don't think they really need to be considered important at this point in time. diff --git a/results/classifier/gemma3:12b/hypervisor/858 b/results/classifier/gemma3:12b/hypervisor/858 new file mode 100644 index 00000000..5c6db65e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/858 @@ -0,0 +1,12 @@ + +qemu-system-x86_64: WHPX: Unexpected VP exit code 4 +Description of problem: +Qemu closes and prints following message: + +WHPX: setting APIC emulation mode in the hypervisor +Windows Hypervisor Platform accelerator is operational +whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005) +qemu-system-x86_64: WHPX: Unexpected VP exit code 4 +Steps to reproduce: +1. build OVMF firmware from edk2 +2. run cmd : qemu-system-x86_64 -accel whpx --bios D:\Projects\FW\uefi\edk2\Build\OvmfX64\DEBUG_VS2019\FV\OVMF.fd diff --git a/results/classifier/gemma3:12b/hypervisor/864 b/results/classifier/gemma3:12b/hypervisor/864 new file mode 100644 index 00000000..ca986b2a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/864 @@ -0,0 +1,16 @@ + +HVF virtual counter diverges from CLOCK_VIRTUAL when the host sleeps +Description of problem: +HVF's virtual counter diverges from `CLOCK_VIRTUAL` when the host sleeps and causes the inconsistency between Linux's system counter and everything else. + +HVF's virtual counter apparently relies on something similar to `mach_absolute_time`, which stops when the host sleeps and resumes after it wakes up. However, `CLOCK_VIRTUAL` is implemented with `mach_continuous_time`, which continues even while the host sleeps. Linux uses the virtual counter as the source of the system counter and sees inconsistencies between the system counter and the other devices. +Steps to reproduce: +1. Launch Fedora. +2. Compare the time shown at the top of the guest display and one at the top of the host display. The difference should be less than 2 minutes. +3. Let the host sleep for 3 minutes. +4. Compare the times again. The difference is now greater than 2 minutes. +Additional information: +Here are solutions I've came up with so far. There are trade-offs but any of them should be better than the current situation. I'm happy to implement one if the maintainers have decided which one is the best or figure out a superior alternative. +- Implement `cpus_get_virtual_clock` of `AccelOpsClass` with `mach_absolute_time`. It would make HVF inconsistent with the other accelerators. Linux also expects the virtual clock is "continuous" and it leaves the divergence from the real time. +- Request XNU `HOST_NOTIFY_CALENDAR_CHANGE` to update the virtual clock with the continuous time. The interface is undocumented. +- Use `IORegisterForSystemPower` to update the virtual clock with the continuous time. It is undocumented that the interface handles every cases where `mach_absolute_time` and `mach_continuous_time`, but it actually does if I read XNU's source code correctly. diff --git a/results/classifier/gemma3:12b/hypervisor/864490 b/results/classifier/gemma3:12b/hypervisor/864490 new file mode 100644 index 00000000..fb497cda --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/864490 @@ -0,0 +1,11 @@ + +Windows 2008 x64 (SBS Server) freezes randomly when using more than 1 CPU core + +This issue has been giving headache to us since a long time. +Difficult to reproduce as it happens randomly. +We had this issue when we ran Windows 2008 x64 or Windows SBS Server guests in either XEN 3.3 or Proxmox environments. +When only one CPU core is assigned to the guest, everything is fine. If 2 or more cores are assigned, the guest stops responding after several hours - and in the host machine one of the cores is using 100%. The only thing that helps is resetting the guest. + +I am ready to provide logs/crashdumps if needed, because we want to help resolve this issue. I saw some posts on the web of people having the same problems - for some of the workaround was to fix some BIOS settings, but we did not have success with those (e.g. disabling C1E Support and Intel C-State ) + +Server is running on Intel® Core™ i7-920 Quad-Core, 24 Gig RAM. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/882 b/results/classifier/gemma3:12b/hypervisor/882 new file mode 100644 index 00000000..d56513cf --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/882 @@ -0,0 +1,474 @@ + +Build fails: error: ‘struct statx’ has no member named ‘stx_mnt_id’ +Description of problem: +When trying to build qemu (both version 6.2.0 and upstream git), the build fails with the mentioned error message +Steps to reproduce: +1. Configure qemu with the following arguments (target list removed for the sake of brevity): +``` +./configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --smbd=/usr/bin/smbd \ + --enable-modules \ + --enable-sdl \ + --enable-slirp=system \ + --disable-werror +``` +2. Try to build qemu +3. Build fails on target tools/virtiofsd/virtiofsd.p/passthrough_ll.c.o +Additional information: +Meson output: +``` ++ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --enable-slirp=system --disable-werror --target-list=x86_64-softmmu,x86_64-linux-user,aarch64-softmmu,aarch64-linux-user,ppc64-softmmu,ppc64-linux-user,riscv32-softmmu,riscv32-linux-user,riscv64-softmmu,riscv64-linux-user,arm-softmmu,arm-linux-user,avr-softmmu +Using './build' as the directory for build output +The Meson build system +Version: 0.61.2 +Source dir: /home/mae/dev/qemubuild/qemu +Build dir: /home/mae/dev/qemubuild/qemu/build +Build type: native build +Project name: qemu +Project version: 6.2.50 +C compiler for the host machine: gcc -m64 -mcx16 (gcc 11.2.0 "gcc (GCC) 11.2.0") +C linker for the host machine: gcc -m64 -mcx16 ld.bfd 2.37 +Host machine cpu family: x86_64 +Host machine cpu: x86_64 +Program sh found: YES (/usr/bin/sh) +Program python3 found: YES (/usr/bin/python) +Program bzip2 found: YES (/usr/bin/bzip2) +C++ compiler for the host machine: g++ -m64 -mcx16 (gcc 11.2.0 "g++ (GCC) 11.2.0") +C++ linker for the host machine: g++ -m64 -mcx16 ld.bfd 2.37 +Program cgcc found: NO +Library m found: YES +Run-time dependency threads found: YES +Library util found: YES +Run-time dependency appleframeworks found: NO (tried framework) +Found pkg-config: /usr/bin/pkg-config (1.8.0) +Run-time dependency pixman-1 found: YES 0.40.0 +Run-time dependency zlib found: YES 1.2.11 +Has header "libaio.h" : YES +Library aio found: YES +Run-time dependency liburing found: YES 2.0 +Run-time dependency libnfs found: YES 5.0.1 +Run-time dependency appleframeworks found: NO (tried framework) +Run-time dependency libseccomp found: YES 2.5.3 +Has header "cap-ng.h" : YES +Library cap-ng found: YES +Run-time dependency xkbcommon found: YES 1.4.0 +Has header "libvdeplug.h" : YES +Library vdeplug found: YES +Run-time dependency libpulse found: YES 15.0 +Run-time dependency alsa found: YES 1.2.6.1 +Run-time dependency jack found: NO (tried pkgconfig) +Run-time dependency spice-protocol found: YES 0.14.4 +Run-time dependency spice-server found: YES 0.15.0 +Library rt found: YES +Run-time dependency libiscsi found: YES 1.19.0 +Run-time dependency libzstd found: YES 1.5.2 +Run-time dependency virglrenderer found: YES 0.9.1 +Run-time dependency libcurl found: YES 7.81.0 +Run-time dependency libudev found: YES 250 +Library mpathpersist found: NO +Run-time dependency ncursesw found: YES 6.3.20211021 +Has header "brlapi.h" : NO +Run-time dependency sdl2 found: YES 2.0.18 +Run-time dependency sdl2_image found: YES 2.0.5 +Library rados found: NO +Has header "rbd/librbd.h" : NO +Run-time dependency glusterfs-api found: NO (tried pkgconfig) +Run-time dependency libssh found: YES 0.9.6 +Has header "bzlib.h" : YES +Library bz2 found: YES +Has header "lzfse.h" : NO +Has header "sys/soundcard.h" : YES +Run-time dependency gbm found: YES 21.3.1 +Run-time dependency gnutls found: YES 3.7.3 +Run-time dependency gtk+-3.0 found: YES 3.24.31 +Run-time dependency gtk+-x11-3.0 found: YES 3.24.31 +Run-time dependency vte-2.91 found: YES 0.66.2 +Run-time dependency x11 found: YES 1.7.3.1 +Run-time dependency libpng found: YES 1.6.37 +Run-time dependency libjpeg found: YES 2.1.2 +Has header "sasl/sasl.h" : YES +Library sasl2 found: YES +Has header "security/pam_appl.h" : YES +Library pam found: YES +Has header "snappy-c.h" : YES +Library snappy found: YES +Has header "lzo/lzo1x.h" : YES +Library lzo2 found: YES +Run-time dependency libcacard found: YES 2.7.0 +Run-time dependency u2f-emu found: NO (tried pkgconfig) +Run-time dependency libusbredirparser-0.5 found: YES 0.12.0 +Run-time dependency libusb-1.0 found: YES 1.0.25 +Run-time dependency libpmem found: NO (tried pkgconfig) +Run-time dependency libdaxctl found: YES 72.1+ +Run-time dependency libtasn1 found: YES 4.18.0 +Run-time dependency libkeyutils found: YES 1.6.3 +Checking for function "gettid" : YES +Run-time dependency libselinux found: NO (tried pkgconfig) +Run-time dependency fuse3 found: YES 3.10.5 +Run-time dependency libbpf found: YES 0.7.0 +Has header "sys/epoll.h" : YES +Has header "linux/magic.h" : YES +Has header "valgrind/valgrind.h" : YES +Has header "linux/btrfs.h" : YES +Has header "libdrm/drm.h" : YES +Has header "pty.h" : YES +Has header "sys/disk.h" : NO +Has header "sys/ioccom.h" : NO +Has header "sys/kcov.h" : NO +Checking for function "accept4" : YES +Checking for function "clock_adjtime" : YES +Checking for function "dup3" : YES +Checking for function "fallocate" : YES +Checking for function "posix_fallocate" : YES +Checking for function "posix_memalign" : YES +Checking for function "ppoll" : YES +Checking for function "preadv" : YES +Checking for function "sem_timedwait" with dependency threads: YES +Checking for function "sendfile" : YES +Checking for function "setns" : YES +Checking for function "unshare" : YES +Checking for function "syncfs" : YES +Checking for function "sync_file_range" : YES +Checking for function "timerfd_create" : YES +Checking for function "copy_file_range" : YES +Checking for function "openpty" with dependency -lutil: YES +Checking for function "strchrnul" : YES +Checking for function "system" : YES +Header <byteswap.h> has symbol "bswap_32" : YES +Header <sys/epoll.h> has symbol "epoll_create1" : YES +Header <unistd.h> has symbol "environ" : YES +Header <linux/falloc.h> has symbol "FALLOC_FL_PUNCH_HOLE" : YES +Header <linux/falloc.h> has symbol "FALLOC_FL_KEEP_SIZE" : YES +Header <linux/falloc.h> has symbol "FALLOC_FL_ZERO_RANGE" : YES +Has header "linux/fiemap.h" : YES +Header <linux/fs.h> has symbol "FS_IOC_FIEMAP" : YES +Checking for function "getrandom" : YES +Header <sys/random.h> has symbol "GRND_NONBLOCK" : YES +Header <sys/inotify.h> has symbol "inotify_init" : YES +Header <sys/inotify.h> has symbol "inotify_init1" : YES +Header <machine/bswap.h> has symbol "bswap32" : NO +Header <sys/prctl.h> has symbol "PR_SET_TIMERSLACK" : YES +Header <linux/rtnetlink.h> has symbol "IFLA_PROTO_DOWN" : YES +Header <sys/sysmacros.h> has symbol "makedev" : YES +Header <getopt.h> has symbol "optreset" : NO +Header <netinet/in.h> has symbol "IPPROTO_MPTCP" : YES +Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO +Checking whether type "struct stat" has member "st_atim" : YES +Checking for type "struct iovec" : YES +Checking for type "struct utmpx" : YES +Checking for type "struct mmsghdr" : YES +Program scripts/minikconf.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/scripts/minikconf.py) +Configuring x86_64-softmmu-config-target.h using configuration +Configuring x86_64-softmmu-config-devices.mak with command +Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/x86_64-softmmu-config-devices.mak.d +Configuring x86_64-softmmu-config-devices.h using configuration +Configuring x86_64-linux-user-config-target.h using configuration +Configuring aarch64-softmmu-config-target.h using configuration +Configuring aarch64-softmmu-config-devices.mak with command +Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/aarch64-softmmu-config-devices.mak.d +Configuring aarch64-softmmu-config-devices.h using configuration +Configuring aarch64-linux-user-config-target.h using configuration +Configuring ppc64-softmmu-config-target.h using configuration +Configuring ppc64-softmmu-config-devices.mak with command +Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/ppc64-softmmu-config-devices.mak.d +Configuring ppc64-softmmu-config-devices.h using configuration +Configuring ppc64-linux-user-config-target.h using configuration +Configuring riscv32-softmmu-config-target.h using configuration +Configuring riscv32-softmmu-config-devices.mak with command +Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/riscv32-softmmu-config-devices.mak.d +Configuring riscv32-softmmu-config-devices.h using configuration +Configuring riscv32-linux-user-config-target.h using configuration +Configuring riscv64-softmmu-config-target.h using configuration +Configuring riscv64-softmmu-config-devices.mak with command +Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/riscv64-softmmu-config-devices.mak.d +Configuring riscv64-softmmu-config-devices.h using configuration +Configuring riscv64-linux-user-config-target.h using configuration +Configuring arm-softmmu-config-target.h using configuration +Configuring arm-softmmu-config-devices.mak with command +Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/arm-softmmu-config-devices.mak.d +Configuring arm-softmmu-config-devices.h using configuration +Configuring arm-linux-user-config-target.h using configuration +Configuring avr-softmmu-config-target.h using configuration +Configuring avr-softmmu-config-devices.mak with command +Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/avr-softmmu-config-devices.mak.d +Configuring avr-softmmu-config-devices.h using configuration +Program scripts/make-config-poison.sh found: YES (/home/mae/dev/qemubuild/qemu/scripts/make-config-poison.sh) +Run-time dependency capstone found: NO (tried pkgconfig) +Configuring capstone-defs.h using configuration +Run-time dependency slirp found: YES 4.6.1 +Library fdt found: YES +Configuring config-host.h using configuration +Program scripts/hxtool found: YES (/home/mae/dev/qemubuild/qemu/scripts/hxtool) +Program scripts/shaderinclude.pl found: YES (/usr/bin/env perl /home/mae/dev/qemubuild/qemu/scripts/shaderinclude.pl) +Program scripts/qapi-gen.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/scripts/qapi-gen.py) +Program scripts/qemu-version.sh found: YES (/home/mae/dev/qemubuild/qemu/scripts/qemu-version.sh) + +Executing subproject libvhost-user + +libvhost-user| Project name: libvhost-user +libvhost-user| Project version: undefined +libvhost-user| C compiler for the host machine: gcc -m64 -mcx16 (gcc 11.2.0 "gcc (GCC) 11.2.0") +libvhost-user| C linker for the host machine: gcc -m64 -mcx16 ld.bfd 2.37 +libvhost-user| Dependency threads found: YES unknown (cached) +libvhost-user| Dependency glib-2.0 found: YES 2.71.2 (overridden) +libvhost-user| Build targets in project: 10 +libvhost-user| Subproject libvhost-user finished. + +Program scripts/decodetree.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/scripts/decodetree.py) +Program ../scripts/modules/module_block.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/block/../scripts/modules/module_block.py) +Program ../scripts/block-coroutine-wrapper.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/block/../scripts/block-coroutine-wrapper.py) +Program scripts/modinfo-collect.py found: YES (/home/mae/dev/qemubuild/qemu/scripts/modinfo-collect.py) +Program scripts/modinfo-generate.py found: YES (/home/mae/dev/qemubuild/qemu/scripts/modinfo-generate.py) +Program nm found: YES +Program scripts/undefsym.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/scripts/undefsym.py) +Program scripts/feature_to_c.sh found: YES (/bin/sh /home/mae/dev/qemubuild/qemu/scripts/feature_to_c.sh) +Configuring 50-qemu-gpu.json using configuration +Configuring 50-qemu-virtiofsd.json using configuration +Configuring 50-edk2-i386-secure.json using configuration +Configuring 50-edk2-x86_64-secure.json using configuration +Configuring 60-edk2-aarch64.json using configuration +Configuring 60-edk2-arm.json using configuration +Configuring 60-edk2-i386.json using configuration +Configuring 60-edk2-x86_64.json using configuration +Program qemu-keymap found: NO +Program cp found: YES (/usr/bin/cp) +Program sphinx-build-3 sphinx-build found: NO +Program python3 found: YES (/usr/bin/python) +Program diff found: YES (/usr/bin/diff) +Program dbus-daemon found: YES (/usr/bin/dbus-daemon) +Program initrd-stress.sh found: YES (/home/mae/dev/qemubuild/qemu/tests/migration/initrd-stress.sh) +Program xgettext found: YES (/usr/bin/xgettext) +Build targets in project: 744 + +qemu 6.2.50 + + Directories + Install prefix : /usr + BIOS directory : share/qemu + firmware path : /usr/share/qemu-firmware + binary directory : bin + library directory : lib + module directory : lib/qemu + libexec directory : lib/qemu + include directory : include + config directory : /etc + local state directory : /var + Manual directory : share/man + Doc directory : /usr/share/doc + Build directory : /home/mae/dev/qemubuild/qemu/build + Source path : /home/mae/dev/qemubuild/qemu + GIT submodules : ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone + + Host binaries + git : git + make : make + python : /usr/bin/python (version: 3.10) + sphinx-build : NO + gdb : /usr/bin/gdb + genisoimage : + smbd : "/usr/bin/smbd" + + Configurable features + Documentation : NO + system-mode emulation : YES + user-mode emulation : YES + block layer : YES + Install blobs : YES + module support : YES + alternative module path : NO + fuzzing support : NO + Audio drivers : pa oss + Trace backends : log + D-Bus display : YES + QOM debugging : YES + vhost-kernel support : YES + vhost-net support : YES + vhost-crypto support : YES + vhost-scsi support : YES + vhost-vsock support : YES + vhost-user support : YES + vhost-user-blk server support: YES + vhost-user-fs support : YES + vhost-vdpa support : YES + build guest agent : YES + + Compilation + host CPU : x86_64 + host endianness : little + C compiler : gcc -m64 -mcx16 + Host C compiler : gcc -m64 -mcx16 + C++ compiler : g++ -m64 -mcx16 + CFLAGS : -march=native -mtune=native -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -O2 -g + CXXFLAGS : -march=native -mtune=native -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -O2 -g + LDFLAGS : -march=native -mtune=native -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now + QEMU_CFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong + QEMU_LDFLAGS : -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -fstack-protector-strong + profiler : NO + link-time optimization (LTO) : NO + PIE : YES + static build : NO + malloc trim support : YES + membarrier : NO + debug stack usage : NO + mutex debugging : NO + memory allocator : system + avx2 optimization : YES + avx512f optimization : NO + gprof enabled : NO + gcov : NO + thread sanitizer : NO + CFI support : NO + strip binaries : NO + sparse : NO + mingw32 support : NO + x86_64 tests : gcc + + Targets and accelerators + KVM support : YES + HAX support : NO + HVF support : NO + WHPX support : NO + NVMM support : NO + Xen support : NO + TCG support : YES + TCG backend : native (x86_64) + TCG plugins : YES + TCG debug enabled : NO + target list : x86_64-softmmu x86_64-linux-user aarch64-softmmu aarch64-linux-user ppc64-softmmu ppc64-linux-user riscv32-softmmu riscv32-linux-user riscv64-softmmu riscv64-linux-user arm-softmmu arm-linux-user avr-softmmu + default devices : YES + out of process emulation : YES + + Block layer support + coroutine backend : ucontext + coroutine pool : YES + Block whitelist (rw) : + Block whitelist (ro) : + Use block whitelist in tools : NO + VirtFS support : YES + build virtiofs daemon : YES + Live block migration : YES + replication support : YES + bochs support : YES + cloop support : YES + dmg support : YES + qcow v1 support : YES + vdi support : YES + vvfat support : YES + qed support : YES + parallels support : YES + FUSE exports : YES 3.10.5 + + Crypto + TLS priority : "NORMAL" + GNUTLS support : YES 3.7.3 + GNUTLS crypto : YES + libgcrypt : NO + nettle : NO + crypto afalg : NO + rng-none : NO + Linux keyring : YES + + Dependencies + SDL support : YES + SDL image support : YES 2.0.5 + GTK support : YES + pixman : YES 0.40.0 + VTE support : YES 0.66.2 + slirp support : YES 4.6.1 + libtasn1 : YES 4.18.0 + PAM : YES + iconv support : YES + curses support : YES + virgl support : YES 0.9.1 + curl support : YES 7.81.0 + Multipath support : NO + VNC support : YES + VNC SASL support : YES + VNC JPEG support : YES 2.1.2 + VNC PNG support : YES 1.6.37 + OSS support : YES + ALSA support : YES 1.2.6.1 + PulseAudio support : YES 15.0 + JACK support : NO + brlapi support : NO + vde support : YES + netmap support : NO + l2tpv3 support : YES + Linux AIO support : YES + Linux io_uring support : YES 2.0 + ATTR/XATTR support : YES + RDMA support : NO + PVRDMA support : NO + fdt support : system + libcap-ng support : YES + bpf support : YES 0.7.0 + spice protocol support : YES 0.14.4 + spice server support : YES 0.15.0 + rbd support : NO + smartcard support : YES 2.7.0 + U2F support : NO + libusb : YES 1.0.25 + usb net redir : YES 0.12.0 + OpenGL support : YES + GBM : YES 21.3.1 + libiscsi support : YES 1.19.0 + libnfs support : YES 5.0.1 + seccomp support : YES 2.5.3 + GlusterFS support : NO + TPM support : YES + libssh support : YES 0.9.6 + lzo support : YES + snappy support : YES + bzip2 support : YES + lzfse support : NO + zstd support : YES 1.5.2 + NUMA host support : YES + capstone : internal + libpmem support : NO + libdaxctl support : YES 72.1+ + libudev : YES 250 + FUSE lseek : YES + selinux : NO + + Subprojects + libvhost-user : YES + + User defined options + Native files : config-meson.cross + bindir : /usr/bin + datadir : /usr/share + debug : true + includedir : /usr/include + libdir : /usr/lib + libexecdir : /usr/lib/qemu + localedir : /usr/share/locale + localstatedir : /var + mandir : /usr/share/man + optimization : 2 + prefix : /usr + sysconfdir : /etc + werror : false + b_coverage : false + b_lto : false + b_pie : true + audio_drv_list : default + capstone : auto + cfi : false + default_devices : true + docdir : /usr/share/doc + fdt : auto + qemu_firmwarepath : /usr/share/qemu-firmware + qemu_suffix : qemu + sdl : enabled + slirp : system + sphinx_build : + tcg : enabled + trace_file : trace + xen : disabled + +Found ninja-1.10.2 at /usr/bin/ninja +``` diff --git a/results/classifier/gemma3:12b/hypervisor/886621 b/results/classifier/gemma3:12b/hypervisor/886621 new file mode 100644 index 00000000..4fe7b50e --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/886621 @@ -0,0 +1,293 @@ + +Mac OS X Lion: segmentation fault + + +Process: qemu [5680] +Path: /usr/local/xeos-build/qemu/bin/qemu +Identifier: qemu +Version: ??? (???) +Code Type: X86-64 (Native) +Parent Process: make [5677] + +Date/Time: 2011-11-05 18:53:25.574 +0100 +OS Version: Mac OS X 10.7.2 (11C74) +Report Version: 9 +Sleep/Wake UUID: 3C81B8F7-0321-4621-923C-AB655F2CC701 + +Interval Since Last Report: 503994 sec +Crashes Since Last Report: 35 +Per-App Crashes Since Last Report: 9 +Anonymous UUID: 28E7367A-4697-43A4-8D12-005F1917DFD3 + +Crashed Thread: 0 Dispatch queue: com.apple.main-thread + +Exception Type: EXC_BAD_ACCESS (SIGSEGV) +Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000003a + +VM Regions Near 0x3a: +--> + __TEXT 0000000107c75000-0000000107ebc000 [ 2332K] r-x/rwx SM=COW /usr/local/xeos-build/qemu/bin/qemu + +Application Specific Information: +objc[5680]: garbage collection is OFF + +Thread 0 Crashed:: Dispatch queue: com.apple.main-thread +0 qemu 0x0000000107d9d0ed 0x107c75000 + 1212653 +1 qemu 0x0000000107dabc39 0x107c75000 + 1272889 +2 ??? 0x000000010c3b007c 0 + 4500160636 + +Thread 1:: Dispatch queue: com.apple.libdispatch-manager +0 libsystem_kernel.dylib 0x00007fff85abb7e6 kevent + 10 +1 libdispatch.dylib 0x00007fff8e7b15be _dispatch_mgr_invoke + 923 +2 libdispatch.dylib 0x00007fff8e7b014e _dispatch_mgr_thread + 54 + +Thread 2: +0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 +1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 +2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 + +Thread 3: +0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 +1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 +2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 + +Thread 4: +0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 +1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 +2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 + +Thread 5: +0 libsystem_kernel.dylib 0x00007fff85abb036 __sigwait + 10 +1 libsystem_c.dylib 0x00007fff8583aaab sigwait + 68 +2 qemu 0x0000000107d221ef 0x107c75000 + 709103 +3 libsystem_c.dylib 0x00007fff858848bf _pthread_start + 335 +4 libsystem_c.dylib 0x00007fff85887b75 thread_start + 13 + +Thread 0 crashed with X86 Thread State (64-bit): + rax: 0x5433ade07f7c29e7 rbx: 0x0000000000000010 rcx: 0x0000000000000000 rdx: 0x0000000000002000 + rdi: 0x0000000000000010 rsi: 0x0000000000000000 rbp: 0x00007fff678714a0 rsp: 0x00007fff67871470 + r8: 0x0000000109fe8000 r9: 0x0000000000000fff r10: 0x00007fa7c185c01d r11: 0x0000000000000246 + r12: 0x00000001087ae368 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000001f80 + rip: 0x0000000107d9d0ed rfl: 0x0000000000010202 cr2: 0x000000000000003a +Logical CPU: 6 + +Binary Images: + 0x107c75000 - 0x107ebbff7 +qemu (??? - ???) <FECE8C8E-BD8E-34F1-B222-32D79C7A0037> /usr/local/xeos-build/qemu/bin/qemu + 0x1087cb000 - 0x1088b5fe7 +libglib-2.0.0.dylib (2704.0.0 - compatibility 2704.0.0) <5E6151CC-61F8-3335-A6FA-EFDD71474FA6> /usr/local/macmade/sw/glib/lib/libglib-2.0.0.dylib + 0x108917000 - 0x10891ffff +libintl.8.dylib (9.1.0 - compatibility 9.0.0) <7D75E177-3172-2F78-1E08-1118A3D2D2A9> /usr/local/webstart/sw/gettext/lib/libintl.8.dylib + 0x108928000 - 0x108949fff +libpng12.0.dylib (23.0.0 - compatibility 23.0.0) <FDE69E98-1D25-EEA1-99CF-F0A04A9AD7FF> /usr/local/webstart/sw/lib-png/lib/libpng12.0.dylib + 0x10895a000 - 0x10897aff7 +libjpeg.62.dylib (63.0.0 - compatibility 63.0.0) <AD465C8A-66A4-E794-CA9A-96FB1B4D6CF0> /usr/local/webstart/sw/lib-jpeg/lib/libjpeg.62.dylib + 0x108987000 - 0x108a67ff7 +libiconv.2.dylib (8.0.0 - compatibility 8.0.0) <54A03BBE-E505-9FF1-79AA-D4D5139BBF9C> /usr/local/webstart/sw/lib-iconv/lib/libiconv.2.dylib + 0x7fff67875000 - 0x7fff678a9ac7 dyld (195.5 - ???) <4A6E2B28-C7A2-3528-ADB7-4076B9836041> /usr/lib/dyld + 0x7fff8547d000 - 0x7fff8547efff libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib + 0x7fff8582b000 - 0x7fff8582efff com.apple.help (1.3.2 - 42) <AB67588E-7227-3993-927F-C9E6DAC507FD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help + 0x7fff8582f000 - 0x7fff85835fff libmacho.dylib (800.0.0 - compatibility 1.0.0) <D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC> /usr/lib/system/libmacho.dylib + 0x7fff85836000 - 0x7fff85913fef libsystem_c.dylib (763.12.0 - compatibility 1.0.0) <FF69F06E-0904-3C08-A5EF-536FAFFFDC22> /usr/lib/system/libsystem_c.dylib + 0x7fff85914000 - 0x7fff85914fff com.apple.audio.units.AudioUnit (1.7.1 - 1.7.1) <04C10813-CCE5-3333-8C72-E8E35E417B3B> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit + 0x7fff85915000 - 0x7fff8591bfff IOSurface (??? - ???) <06FA3FDD-E6D5-391F-B60D-E98B169DAB1B> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface + 0x7fff85964000 - 0x7fff85972fff com.apple.NetAuth (1.0 - 3.0) <F384FFFD-70F6-3B1C-A886-F5B446E456E7> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth + 0x7fff85aa4000 - 0x7fff85ac4fff libsystem_kernel.dylib (1699.22.73 - compatibility 1.0.0) <69F2F501-72D8-3B3B-8357-F4418B3E1348> /usr/lib/system/libsystem_kernel.dylib + 0x7fff85ac5000 - 0x7fff85b10ff7 com.apple.SystemConfiguration (1.11.1 - 1.11) <F832FE21-5509-37C6-B1F1-48928F31BE45> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration + 0x7fff85c2a000 - 0x7fff85c39ff7 com.apple.opengl (1.7.5 - 1.7.5) <2945F1A6-910C-3596-9988-5701B04BD821> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL + 0x7fff85c3a000 - 0x7fff85c3eff7 com.apple.CommonPanels (1.2.5 - 94) <0BB2C436-C9D5-380B-86B5-E355A7711259> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels + 0x7fff85ebb000 - 0x7fff85fbefff libsqlite3.dylib (9.6.0 - compatibility 9.0.0) <7F60B0FF-4946-3639-89AB-B540D318B249> /usr/lib/libsqlite3.dylib + 0x7fff85fbf000 - 0x7fff86063fef com.apple.ink.framework (1.3.2 - 110) <F69DBD44-FEC8-3C14-8131-CC0245DBBD42> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink + 0x7fff860c5000 - 0x7fff860cafff libpam.2.dylib (3.0.0 - compatibility 3.0.0) <D952F17B-200A-3A23-B9B2-7C1F7AC19189> /usr/lib/libpam.2.dylib + 0x7fff860dd000 - 0x7fff86147fff com.apple.framework.IOKit (2.0 - ???) <87D55F1D-CDB5-3D13-A5F9-98EA4E22F8EE> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit + 0x7fff86148000 - 0x7fff8614ffff libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib + 0x7fff8627e000 - 0x7fff862abfe7 libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <095FDD3C-3961-3865-A59B-A5B0A4B8B923> /usr/lib/libSystem.B.dylib + 0x7fff862ac000 - 0x7fff86314ff7 com.apple.Symbolication (1.2 - 89) <1D7F9E72-B1B6-30CF-AC8A-23A763930A92> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication + 0x7fff86315000 - 0x7fff86316ff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib + 0x7fff8633a000 - 0x7fff8634cff7 libbsm.0.dylib (??? - ???) <349BB16F-75FA-363F-8D98-7A9C3FA90A0D> /usr/lib/libbsm.0.dylib + 0x7fff8634d000 - 0x7fff863b5ff7 com.apple.audio.CoreAudio (4.0.1 - 4.0.1) <7966E3BE-376B-371A-A21D-9BD763C0BAE7> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio + 0x7fff86411000 - 0x7fff86423ff7 libsasl2.2.dylib (3.15.0 - compatibility 3.0.0) <6245B497-784B-355C-98EF-2DC6B45BF05C> /usr/lib/libsasl2.2.dylib + 0x7fff86428000 - 0x7fff86462fff libncurses.5.4.dylib (5.4.0 - compatibility 5.4.0) <387DE593-9CC5-38C7-911B-A5F2264D34F2> /usr/lib/libncurses.5.4.dylib + 0x7fff86463000 - 0x7fff864a2ff7 libGLImage.dylib (??? - ???) <2D1D8488-EC5F-3229-B983-CFDE0BB37586> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib + 0x7fff864a3000 - 0x7fff86545ff7 com.apple.securityfoundation (5.0 - 55005) <0D59908C-A61B-389E-AF37-741ACBBA6A94> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation + 0x7fff86546000 - 0x7fff865cbff7 com.apple.Heimdal (2.1 - 2.0) <C92E327E-CB5F-3C9B-92B0-F1680095C8A3> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal + 0x7fff865cc000 - 0x7fff865d0fff libCGXType.A.dylib (600.0.0 - compatibility 64.0.0) <5EEAD17D-006C-3855-8093-C7A4A97EE0D0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib + 0x7fff865d1000 - 0x7fff8664cff7 com.apple.print.framework.PrintCore (7.1 - 366.1) <3F140DEB-9F87-3672-97CC-F983752581AC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore + 0x7fff8664d000 - 0x7fff86654ff7 com.apple.CommerceCore (1.0 - 17) <AA783B87-48D4-3CA6-8FF6-0316396022F4> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore + 0x7fff86655000 - 0x7fff86655fff com.apple.Accelerate.vecLib (3.7 - vecLib 3.7) <C06A140F-6114-3B8B-B080-E509303145B8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib + 0x7fff86656000 - 0x7fff8665afff libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib + 0x7fff8665b000 - 0x7fff86768fff libJP2.dylib (??? - ???) <6052C973-9354-35CB-AAB9-31D00D8786F9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib + 0x7fff86769000 - 0x7fff867acff7 libRIP.A.dylib (600.0.0 - compatibility 64.0.0) <2B1571E1-8E87-364E-BC36-C9C9B5D3EAC4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib + 0x7fff867ad000 - 0x7fff86d91fff libBLAS.dylib (??? - ???) <C34F6D88-187F-33DC-8A68-C0C9D1FA36DF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib + 0x7fff86d92000 - 0x7fff86da4ff7 libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib + 0x7fff87016000 - 0x7fff8701cfff libGFXShared.dylib (??? - ???) <343AE6C0-EB02-333C-8D35-DF6093B92758> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib + 0x7fff8701d000 - 0x7fff87290fff com.apple.CoreImage (7.82 - 1.0.1) <282801B6-5D80-3E2C-88A4-00FE29906D5A> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage + 0x7fff872da000 - 0x7fff87315fff com.apple.LDAPFramework (3.0 - 120.1) <0C23534F-A8E7-3144-B2B2-50F9875101E2> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP + 0x7fff87322000 - 0x7fff87524fff libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <38CD6ED3-C8E4-3CCD-89AC-9C3198803101> /usr/lib/libicucore.A.dylib + 0x7fff87a4c000 - 0x7fff87a4dfff libsystem_sandbox.dylib (??? - ???) <8D14139B-B671-35F4-9E5A-023B4C523C38> /usr/lib/system/libsystem_sandbox.dylib + 0x7fff87b4f000 - 0x7fff87b4ffff libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib + 0x7fff87b50000 - 0x7fff87ba7fff libTIFF.dylib (??? - ???) <FF0D9A24-6956-3F03-81EA-3EEAD22C9DB8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib + 0x7fff87c87000 - 0x7fff8839a587 com.apple.CoreGraphics (1.600.0 - ???) <A9F2451E-6F60-350E-A6E5-539669B53074> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics + 0x7fff8839b000 - 0x7fff883b1ff7 com.apple.ImageCapture (7.0 - 7.0) <69E6E2E1-777E-332E-8BCF-4F0611517DD0> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture + 0x7fff883b2000 - 0x7fff883b9fff com.apple.NetFS (4.0 - 4.0) <B9F41443-679A-31AD-B0EB-36557DAF782B> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS + 0x7fff883d7000 - 0x7fff884b5fff com.apple.ImageIO.framework (3.1.1 - 3.1.1) <13E549F8-5BD6-3BAE-8C33-1D0BD269C081> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO + 0x7fff884b6000 - 0x7fff884b6fff com.apple.Cocoa (6.6 - ???) <021D4214-9C23-3CD8-AFB2-F331697A4508> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa + 0x7fff884b7000 - 0x7fff884b7fff com.apple.ApplicationServices (41 - 41) <03F3FA8F-8D2A-3AB6-A8E3-40B001116339> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices + 0x7fff884b8000 - 0x7fff8861efff com.apple.CFNetwork (520.2.5 - 520.2.5) <406712D9-3F0C-3763-B4EB-868D01F1F042> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork + 0x7fff8861f000 - 0x7fff88943fff com.apple.HIToolbox (1.8 - ???) <A3BE7C59-52E6-3A7F-9B30-24B7DD3E95F2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox + 0x7fff88944000 - 0x7fff88961ff7 com.apple.openscripting (1.3.3 - ???) <A64205E6-D3C5-3E12-B1A0-72243151AF7D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting + 0x7fff88962000 - 0x7fff88c3aff7 com.apple.security (7.0 - 55010) <93713FF4-FE86-3B4C-8150-5FCC7F3320C8> /System/Library/Frameworks/Security.framework/Versions/A/Security + 0x7fff88c5b000 - 0x7fff88cbbfff libvDSP.dylib (325.4.0 - compatibility 1.0.0) <3A7521E6-5510-3FA7-AB65-79693A7A5839> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib + 0x7fff88cbf000 - 0x7fff88d43ff7 com.apple.ApplicationServices.ATS (317.5.0 - ???) <FE629F2D-6BC0-3A58-9844-D8B9A6808A00> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS + 0x7fff88d81000 - 0x7fff88e48ff7 com.apple.ColorSync (4.7.0 - 4.7.0) <F325A9D7-7203-36B7-8C1C-B6A4D5CC73A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync + 0x7fff88e59000 - 0x7fff88e6dff7 com.apple.LangAnalysis (1.7.0 - 1.7.0) <04C31EF0-912A-3004-A08F-CEC27030E0B2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis + 0x7fff88e6e000 - 0x7fff88e79ff7 com.apple.speech.recognition.framework (4.0.19 - 4.0.19) <7ADAAF5B-1D78-32F2-9FFF-D2E3FBB41C2B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition + 0x7fff88f54000 - 0x7fff88f55fff libunc.dylib (24.0.0 - compatibility 1.0.0) <C67B3B14-866C-314F-87FF-8025BEC2CAAC> /usr/lib/system/libunc.dylib + 0x7fff89095000 - 0x7fff89148fff com.apple.CoreText (220.11.0 - ???) <4EA8E2DF-542D-38D5-ADB9-C0DAA73F898B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText + 0x7fff8932e000 - 0x7fff894cdfff com.apple.QuartzCore (1.7 - 270.0) <E8FC9AA4-A5CB-384B-AD29-7190A1387D3E> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore + 0x7fff894f6000 - 0x7fff89530fe7 com.apple.DebugSymbols (2.1 - 87) <E9000AB8-CCE4-3636-871D-E17703814B68> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols + 0x7fff89531000 - 0x7fff8958cff7 com.apple.HIServices (1.10 - ???) <BAB8B422-7047-3D2D-8E0A-13FCF153E4E7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices + 0x7fff89a1d000 - 0x7fff89a6bfff libauto.dylib (??? - ???) <D8AC8458-DDD0-3939-8B96-B6CED81613EF> /usr/lib/libauto.dylib + 0x7fff89a6c000 - 0x7fff89ac0ff7 com.apple.ScalableUserInterface (1.0 - 1) <1873D7BE-2272-31A1-8F85-F70C4D706B3B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface + 0x7fff89ac1000 - 0x7fff89ae0fff libresolv.9.dylib (46.0.0 - compatibility 1.0.0) <33263568-E6F3-359C-A4FA-66AD1300F7D4> /usr/lib/libresolv.9.dylib + 0x7fff89b26000 - 0x7fff89b65fff com.apple.AE (527.7 - 527.7) <B82F7ABC-AC8B-3507-B029-969DD5CA813D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE + 0x7fff89fd5000 - 0x7fff8a1a9fff com.apple.CoreFoundation (6.7.1 - 635.15) <FE4A86C2-3599-3CF8-AD1A-822F1FEA820F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation + 0x7fff8a1aa000 - 0x7fff8a1d3fff libJPEG.dylib (??? - ???) <64D079F9-256A-323B-A837-84628B172F21> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib + 0x7fff8a929000 - 0x7fff8a94dfff com.apple.Kerberos (1.0 - 1) <1F826BCE-DA8F-381D-9C4C-A36AA0EA1CB9> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos + 0x7fff8a94e000 - 0x7fff8a94efff com.apple.CoreServices (53 - 53) <043C8026-8EDD-3241-B090-F589E24062EF> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices + 0x7fff8a94f000 - 0x7fff8a9c4ff7 libc++.1.dylib (19.0.0 - compatibility 1.0.0) <C0EFFF1B-0FEB-3F99-BE54-506B35B555A9> /usr/lib/libc++.1.dylib + 0x7fff8af21000 - 0x7fff8afa4fef com.apple.Metadata (10.7.0 - 627.20) <E00156B0-663A-35EF-A307-A2CEB00F1845> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata + 0x7fff8b02d000 - 0x7fff8b036ff7 libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib + 0x7fff8b06d000 - 0x7fff8b10cfff com.apple.LaunchServices (480.21 - 480.21) <6BFADEA9-5BC1-3B53-A013-488EB7F1AB57> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices + 0x7fff8b10d000 - 0x7fff8b14efff com.apple.QD (3.12 - ???) <4F3C5629-97C7-3E55-AF3C-ACC524929DA2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD + 0x7fff8b14f000 - 0x7fff8b251ff7 libxml2.2.dylib (10.3.0 - compatibility 10.0.0) <D46F371D-6422-31B7-BCE0-D80713069E0E> /usr/lib/libxml2.2.dylib + 0x7fff8b2f6000 - 0x7fff8b2f9fff libCoreVMClient.dylib (??? - ???) <E034C772-4263-3F48-B083-25A758DD6228> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib + 0x7fff8b2fd000 - 0x7fff8b402ff7 libFontParser.dylib (??? - ???) <B9A53808-C97E-3293-9C33-1EA9D4E83EC8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib + 0x7fff8b41e000 - 0x7fff8b449ff7 libxslt.1.dylib (3.24.0 - compatibility 3.0.0) <8051A3FC-7385-3EA9-9634-78FC616C3E94> /usr/lib/libxslt.1.dylib + 0x7fff8b49e000 - 0x7fff8b4a3fff libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib + 0x7fff8b656000 - 0x7fff8b65bfff libcache.dylib (47.0.0 - compatibility 1.0.0) <B7757E2E-5A7D-362E-AB71-785FE79E1527> /usr/lib/system/libcache.dylib + 0x7fff8b65c000 - 0x7fff8b695fe7 libssl.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <79AAEC98-1258-3DA4-B1C0-4120049D390B> /usr/lib/libssl.0.9.8.dylib + 0x7fff8b696000 - 0x7fff8b69bff7 libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib + 0x7fff8b6c6000 - 0x7fff8b6d1ff7 libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib + 0x7fff8b909000 - 0x7fff8bd36fff libLAPACK.dylib (??? - ???) <4F2E1055-2207-340B-BB45-E4F16171EE0D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib + 0x7fff8bd37000 - 0x7fff8bd42fff com.apple.CommonAuth (2.1 - 2.0) <BFDD0A8D-4BEA-39EC-98B3-2E083D7B1ABD> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth + 0x7fff8bd43000 - 0x7fff8bd76ff7 com.apple.GSS (2.1 - 2.0) <9A2C9736-DA10-367A-B376-2C7A584E6C7A> /System/Library/Frameworks/GSS.framework/Versions/A/GSS + 0x7fff8bd77000 - 0x7fff8bd78ff7 libremovefile.dylib (21.0.0 - compatibility 1.0.0) <C6C49FB7-1892-32E4-86B5-25AD165131AA> /usr/lib/system/libremovefile.dylib + 0x7fff8bd79000 - 0x7fff8bd7dfff libdyld.dylib (195.5.0 - compatibility 1.0.0) <F1903B7A-D3FF-3390-909A-B24E09BAD1A5> /usr/lib/system/libdyld.dylib + 0x7fff8bdac000 - 0x7fff8bdc8ff7 com.apple.GenerationalStorage (1.0 - 125) <31F60175-E38D-3C63-8D95-32CFE7062BCB> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage + 0x7fff8bdcd000 - 0x7fff8bdf5ff7 com.apple.CoreVideo (1.7 - 70.1) <98F917B2-FB53-3EA3-B548-7E97B38309A7> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo + 0x7fff8bdf6000 - 0x7fff8be0dfff com.apple.MultitouchSupport.framework (220.62.1 - 220.62.1) <F21C79C0-4B5A-3645-81A6-74F8EFA900CE> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport + 0x7fff8be0e000 - 0x7fff8be34ff7 com.apple.framework.familycontrols (3.0 - 300) <41A6DFC2-EAF5-390A-83A1-C8832528705C> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls + 0x7fff8c071000 - 0x7fff8c155def libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <C5F2392D-B481-3A9D-91BE-3D039FFF4DEC> /usr/lib/libobjc.A.dylib + 0x7fff8c156000 - 0x7fff8c17dfff com.apple.PerformanceAnalysis (1.10 - 10) <2A058167-292E-3C3A-B1F8-49813336E068> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis + 0x7fff8c17e000 - 0x7fff8c1c0ff7 libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <A5B9778E-11C3-3F61-B740-1F2114E967FB> /usr/lib/system/libcommonCrypto.dylib + 0x7fff8c3ff000 - 0x7fff8c452fff libFontRegistry.dylib (??? - ???) <57FBD85F-41A6-3DB9-B5F4-FCC6B260F1AD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib + 0x7fff8c461000 - 0x7fff8c4fbff7 com.apple.SearchKit (1.4.0 - 1.4.0) <4E70C394-773E-3A4B-A93C-59A88ABA9509> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit + 0x7fff8d20f000 - 0x7fff8d24aff7 libsystem_info.dylib (??? - ???) <9C8C2DCB-96DB-3471-9DCE-ADCC26BE2DD4> /usr/lib/system/libsystem_info.dylib + 0x7fff8d24b000 - 0x7fff8d250fff libGIF.dylib (??? - ???) <393E2DB5-9479-39A6-A75A-B5F20B852532> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib + 0x7fff8d251000 - 0x7fff8d268fff com.apple.CFOpenDirectory (10.7 - 144) <9709423E-8484-3B26-AAE8-EF58D1B8FB3F> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory + 0x7fff8d269000 - 0x7fff8d26efff com.apple.OpenDirectory (10.7 - 146) <91A87249-6A2F-3F89-A8DE-0E95C0B54A3A> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory + 0x7fff8d26f000 - 0x7fff8d2c1ff7 libGLU.dylib (??? - ???) <3C9153A0-8499-3DC0-AAA4-9FA6E488BE13> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib + 0x7fff8d2c2000 - 0x7fff8d789fff FaceCoreLight (1.4.7 - compatibility 1.0.0) <E9D2A69C-6E81-358C-A162-510969F91490> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight + 0x7fff8d78a000 - 0x7fff8d792fff libsystem_dnssd.dylib (??? - ???) <7749128E-D0C5-3832-861C-BC9913F774FA> /usr/lib/system/libsystem_dnssd.dylib + 0x7fff8d793000 - 0x7fff8d7bcfff com.apple.CoreServicesInternal (113.8 - 113.8) <C1A3CF1B-BC45-3FC6-82B3-1511EBBA9D51> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal + 0x7fff8d823000 - 0x7fff8d838fff com.apple.speech.synthesis.framework (4.0.74 - 4.0.74) <C061ECBB-7061-3A43-8A18-90633F943295> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis + 0x7fff8e34d000 - 0x7fff8e371ff7 com.apple.RemoteViewServices (1.2 - 39) <862849C8-84C1-32A1-B87E-B29E74778C9F> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices + 0x7fff8e508000 - 0x7fff8e51bff7 libCRFSuite.dylib (??? - ???) <034D4DAA-63F0-35E4-BCEF-338DD7A453DD> /usr/lib/libCRFSuite.dylib + 0x7fff8e7a7000 - 0x7fff8e7a9ff7 com.apple.print.framework.Print (7.1 - 247.1) <8A4925A5-BAA3-373C-9B5D-03E0270C6B12> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print + 0x7fff8e7aa000 - 0x7fff8e7adff7 com.apple.securityhi (4.0 - 1) <B37B8946-BBD4-36C1-ABC6-18EDBC573F03> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI + 0x7fff8e7ae000 - 0x7fff8e7bcfff libdispatch.dylib (187.7.0 - compatibility 1.0.0) <712AAEAC-AD90-37F7-B71F-293FF8AE8723> /usr/lib/system/libdispatch.dylib + 0x7fff8e7bd000 - 0x7fff8e7befff liblangid.dylib (??? - ???) <CACBE3C3-2F7B-3EED-B50E-EDB73F473B77> /usr/lib/liblangid.dylib + 0x7fff8e7cc000 - 0x7fff8e7e9fff libPng.dylib (??? - ???) <3C70A94C-9442-3E11-AF51-C1B0EF81680E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib + 0x7fff8e7ea000 - 0x7fff8e7eafff com.apple.Accelerate (1.7 - Accelerate 1.7) <82DDF6F5-FBC3-323D-B71D-CF7ABC5CF568> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate + 0x7fff8e7eb000 - 0x7fff8e801fff libGL.dylib (??? - ???) <6A473BF9-4D35-34C6-9F8B-86B68091A9AF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib + 0x7fff8e810000 - 0x7fff8e81aff7 liblaunch.dylib (392.18.0 - compatibility 1.0.0) <39EF04F2-7F0C-3435-B785-BF283727FFBD> /usr/lib/system/liblaunch.dylib + 0x7fff8e95f000 - 0x7fff8e9f5ff7 libvMisc.dylib (325.4.0 - compatibility 1.0.0) <642D8D54-F9F5-3FBB-A96C-EEFE94C6278B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib + 0x7fff8e9f6000 - 0x7fff8ec10fef com.apple.CoreData (104 - 358.12) <33B1FA75-7970-3751-9DCC-FF809D3E1FA2> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData + 0x7fff8ef91000 - 0x7fff8f2aaff7 com.apple.Foundation (6.7.1 - 833.20) <D922F590-FDA6-3D89-A271-FD35E2290624> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation + 0x7fff8f2ab000 - 0x7fff8f38cfff com.apple.CoreServices.OSServices (478.29 - 478.29) <B487110E-C942-33A8-A494-3BDEDB88B1CD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices + 0x7fff8f3c8000 - 0x7fff8f3d5fff libCSync.A.dylib (600.0.0 - compatibility 64.0.0) <931F40EB-CA75-3A90-AC97-4DB8E210BC76> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib + 0x7fff8f44d000 - 0x7fff8f4c0fff libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib + 0x7fff8f7e3000 - 0x7fff8f7e3fff com.apple.Carbon (153 - 153) <895C2BF2-1666-3A59-A669-311B1F4F368B> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon + 0x7fff8fb82000 - 0x7fff8fc9aff7 com.apple.DesktopServices (1.6.1 - 1.6.1) <4418EAA6-7163-3A77-ABD3-F8289796C81A> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv + 0x7fff8fc9d000 - 0x7fff8fc9ffff com.apple.TrustEvaluationAgent (2.0 - 1) <1F31CAFF-C1C6-33D3-94E9-11B721761DDF> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent + 0x7fff8fca0000 - 0x7fff8fdf9fff com.apple.audio.toolbox.AudioToolbox (1.7.1 - 1.7.1) <4877267E-F736-3019-85D3-40A32A042A80> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox + 0x7fff8fef9000 - 0x7fff8ff39ff7 libcups.2.dylib (2.9.0 - compatibility 2.0.0) <B7173CA4-CE16-3BAB-8D83-185FCEFA15F5> /usr/lib/libcups.2.dylib + 0x7fff8ff9c000 - 0x7fff900a8fff libcrypto.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <3A8E1F89-5E26-3C8B-B538-81F5D61DBF8A> /usr/lib/libcrypto.0.9.8.dylib + 0x7fff900a9000 - 0x7fff900b7ff7 libkxld.dylib (??? - ???) <65BE345D-6618-3D1A-9E2B-255E629646AA> /usr/lib/system/libkxld.dylib + 0x7fff900b8000 - 0x7fff900beff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib + 0x7fff900cb000 - 0x7fff90204fef com.apple.vImage (5.1 - 5.1) <EB634387-CD15-3246-AC28-5FB368ACCEA2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage + 0x7fff9020d000 - 0x7fff9023dff7 com.apple.DictionaryServices (1.2.1 - 158.2) <3FC86118-7553-38F7-8916-B329D2E94476> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices + 0x7fff9024e000 - 0x7fff90343fff libiconv.2.dylib (7.0.0 - compatibility 7.0.0) <5C40E880-0706-378F-B864-3C2BD922D926> /usr/lib/libiconv.2.dylib + 0x7fff90344000 - 0x7fff9038aff7 libcurl.4.dylib (7.0.0 - compatibility 7.0.0) <EAF61ADC-DC00-34CE-B23E-7238ED54E31D> /usr/lib/libcurl.4.dylib + 0x7fff9038b000 - 0x7fff903a8ff7 libxpc.dylib (77.17.0 - compatibility 1.0.0) <72A16104-2F23-3C22-B474-1953F06F9376> /usr/lib/system/libxpc.dylib + 0x7fff90b3e000 - 0x7fff90b3ffff libdnsinfo.dylib (395.6.0 - compatibility 1.0.0) <718A135F-6349-354A-85D5-430B128EFD57> /usr/lib/system/libdnsinfo.dylib + 0x7fff90b40000 - 0x7fff90e5cff7 com.apple.CoreServices.CarbonCore (960.18 - 960.18) <6020C3FB-6125-3EAE-A55D-1E77E38BEDEA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore + 0x7fff90e9b000 - 0x7fff90e9bfff com.apple.vecLib (3.7 - vecLib 3.7) <9A58105C-B36E-35B5-812C-4ED693F2618F> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib + 0x7fff90fe4000 - 0x7fff90feafff com.apple.DiskArbitration (2.4.1 - 2.4.1) <CEA34337-63DE-302E-81AA-10D717E1F699> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration + 0x7fff91024000 - 0x7fff91027fff libRadiance.dylib (??? - ???) <CD89D70D-F177-3BAE-8A26-644EA7D5E28E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib + 0x7fff91220000 - 0x7fff91222fff libquarantine.dylib (36.0.0 - compatibility 1.0.0) <4C3BFBC7-E592-3939-B376-1C2E2D7C5389> /usr/lib/system/libquarantine.dylib + 0x7fff91223000 - 0x7fff9128bfff com.apple.CoreSymbolication (2.1 - 71) <0715BF39-D53C-3BFE-BBEA-B8EBF7274850> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication + 0x7fff9128c000 - 0x7fff912eefff com.apple.coreui (1.2.1 - 164.1) <F7972630-F696-3FC5-9FCF-A6E1C8771078> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI + 0x7fff912ef000 - 0x7fff9135ffff com.apple.datadetectorscore (3.0 - 179.4) <2A822A13-94B3-3A43-8724-98FDF698BB12> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore + 0x7fff91367000 - 0x7fff91394ff7 com.apple.opencl (1.50.63 - 1.50.63) <DB335C5C-3ABD-38C8-B6A5-8436EE1484D3> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL + 0x7fff91395000 - 0x7fff91f96ff7 com.apple.AppKit (6.7.2 - 1138.23) <5CD2C850-4F52-3BA2-BA11-3107DFD2D23C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit + 0x7fff91f97000 - 0x7fff91f99fff libCVMSPluginSupport.dylib (??? - ???) <61D89F3C-C64D-3733-819F-8AAAE4E2E993> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib + +External Modification Summary: + Calls made by other processes targeting this process: + task_for_pid: 2 + thread_create: 0 + thread_set_state: 0 + Calls made by this process: + task_for_pid: 0 + thread_create: 0 + thread_set_state: 0 + Calls made by all processes on this machine: + task_for_pid: 103153 + thread_create: 1 + thread_set_state: 0 + +VM Region Summary: +ReadOnly portion of Libraries: Total=144.3M resident=100.5M(70%) swapped_out_or_unallocated=43.8M(30%) +Writable regions: Total=185.9M written=3692K(2%) resident=23.0M(12%) swapped_out=0K(0%) unallocated=162.9M(88%) + +REGION TYPE VIRTUAL +=========== ======= +CG backing stores 1496K +CG image 4K +CG raster data 64K +CG shared images 3480K +CoreGraphics 16K +CoreServices 4112K +MALLOC 67.1M +MALLOC guard page 32K +MALLOC_LARGE (reserved) 25.3M reserved VM address space (unallocated) +Memory tag=242 12K +STACK GUARD 24K +Stack 66.5M +VM_ALLOCATE 16.1M +__CI_BITMAP 80K +__DATA 21.1M +__IMAGE 1256K +__LINKEDIT 48.1M +__TEXT 96.2M +__UNICODE 544K +mapped file 32.2M +shared memory 308K +=========== ======= +TOTAL 383.7M +TOTAL, minus reserved VM space 358.4M + +Model: MacBookPro8,3, BootROM MBP81.0047.B24, 4 processors, Intel Core i7, 2.3 GHz, 8 GB, SMC 1.70f3 +Graphics: AMD Radeon HD 6750M, AMD Radeon HD 6750M, PCIe, 1024 MB +Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB +Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020 +Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020 +AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.100.98.75.18) +Bluetooth: Version 4.0.1f4, 2 service, 11 devices, 1 incoming serial ports +Network Service: Wi-Fi, AirPort, en1 +Serial ATA Device: APPLE SSD TS512C, 500.28 GB +Serial ATA Device: MATSHITADVD-R UJ-898 +USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3 +USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfa100000 / 2 +USB Device: BRCM2070 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0xfa110000 / 5 +USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 7 +USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0253, 0xfa120000 / 4 +USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfd100000 / 2 +USB Device: Freecom Hard Drive XS, 0x07ab (Freecom Computer Peripherals), 0xfc8e, 0xfd120000 / 5 +USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/888 b/results/classifier/gemma3:12b/hypervisor/888 new file mode 100644 index 00000000..cd5db783 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/888 @@ -0,0 +1,8 @@ + +TCG <--> KVM behavior difference (TCG bug) +Description of problem: +This app couldn't start in TCG mode in QEMU 6.2, but with KVM everything is good. Until version 6.0 it also works with TCG. +As I checked - problem git commit is 5f9529006ea37560c97b05661a84472431d25b91. +Steps to reproduce: +1. Install Allplayer +2. Try to run it in TCG and KVM mode with QEMU 6.2 diff --git a/results/classifier/gemma3:12b/hypervisor/889 b/results/classifier/gemma3:12b/hypervisor/889 new file mode 100644 index 00000000..8ec34e68 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/889 @@ -0,0 +1,2 @@ + +cc1: error: ‘-fcf-protection’ is not compatible with this target diff --git a/results/classifier/gemma3:12b/hypervisor/899 b/results/classifier/gemma3:12b/hypervisor/899 new file mode 100644 index 00000000..6b9bddaf --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/899 @@ -0,0 +1,15 @@ + +HVF: Ubuntu Server fails to boot Linux 5.4.0-104 +Description of problem: +On macOS with HVF, when Ubuntu Server updates the Linux kernel to 5.4.0-104, it no longer boots and gets stuck at `EFI stub: Exiting boot services and installing virtual address map...`. This is not the case with QEMU 6.0.0 (with @agraf's HVF patches applied). + +It seems like 5.4.0-104 is the culprit because 5.4.0-100 boots fine. +Steps to reproduce: +1. Download Ubuntu Server 20.04 ARM64 ISO: https://ubuntu.com/download/server/arm +2. Run the above QEMU command (make sure networking is disabled so Ubuntu installer does not auto-upgrade the kernel) +3. Install Ubuntu with the default settings and reboot +4. It will not reboot (expected) so Ctrl+C and restart the command adding `-device virtio-net-pci,netdev=net0 -netdev user,id=net0` to the end to get networking +5. Boot into Ubuntu and install 5.4.0-104 kernel: `sudo apt install linux-image-5.4.0-104-generic` +6. Reboot and it will get stuck at `EFI stub: Exiting boot services and installing virtual address map...` +Additional information: + diff --git a/results/classifier/gemma3:12b/hypervisor/908 b/results/classifier/gemma3:12b/hypervisor/908 new file mode 100644 index 00000000..5076e5eb --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/908 @@ -0,0 +1,2 @@ + +since when is qemu-guest-agent included in the qemu package ? diff --git a/results/classifier/gemma3:12b/hypervisor/928 b/results/classifier/gemma3:12b/hypervisor/928 new file mode 100644 index 00000000..6a8b2416 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/928 @@ -0,0 +1,85 @@ + +QEMU/TCG generates #GP instead #SS for RBP/RSP based faults +Description of problem: +Setting RSP/RBP to a non-canonical address and trying to access a memory location based on RSP/RBP generates a #GP under QEMU/TCG while it should generate an #SS exception instead. This difference in behavior triggers a [Xen selftest](https://github.com/xen-project/xen/blob/1145d94c738e/xen/arch/x86/extable.c#L142-L144) violation as can be seen below. + +- A successful run should look like this, e.g. when run under KVM: + +``` +(XEN) Running stub recovery selftests... +(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +(XEN) Fixup #SS[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +``` + +- Under QEMU/TCG it triggers this scary warning: + +``` +(XEN) Running stub recovery selftests... +(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +(XEN) Fixup #GP[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Selftest 2 failed: Opc 02 04 04 c3 expected 12[0000], got 13[0000] +(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +[...] +(XEN) *************************************************** +(XEN) SELFTEST FAILURE: CORRECT BEHAVIOR CANNOT BE GUARANTEED +(XEN) *************************************************** +(XEN) 3... 2... 1... +``` +Steps to reproduce: +The attached program ([noncanon.c](/uploads/34599a2fe23c6bbf1e9efd8cb8704537/noncanon.c)) generates the following output when run on native hardware or under KVM: + +```shell-session +minipli@bell:~$ for i in "" -sp -bp; do ./noncanon $i; done +Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil) +Non-canonical acces via RSP: SIGBUS, signo 7, error 0, code 128, addr (nil) +Non-canonical acces via RBP: SIGBUS, signo 7, error 0, code 128, addr (nil) +``` + +However, when run under QEMU using TCG, I get the following output: + +```shell-session +root@box:~# for i in "" -sp -bp; do ./noncanon $i; done +Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil) +Non-canonical acces via RSP: SIGSEGV, signo 11, error 0, code 128, addr (nil) +Non-canonical acces via RBP: SIGSEGV, signo 11, error 0, code 128, addr (nil) +``` + +Please note how RSP/RBP based access generates SIGSEGV instead of the expected SIGBUS. +Additional information: +The problem seems to be that QEMU always generates a #GP for non-canonical addresses, while it should differentiate, based on the register that led to the non-canonical address: #SS if RSP/RBP is involved, #GP otherwise. However, short of an instruction decoder, I don't see how this can easily be told apart. + +```diff +diff --git a/target/i386/tcg/sysemu/excp_helper.c b/target/i386/tcg/sysemu/excp_helper.c +index e1b6d8868338..ac4a6351a49d 100644 +--- a/target/i386/tcg/sysemu/excp_helper.c ++++ b/target/i386/tcg/sysemu/excp_helper.c +@@ -386,6 +386,7 @@ static int handle_mmu_fault(CPUState *cs, vaddr addr, int size, + sext = (int64_t)addr >> (pg_mode & PG_MODE_LA57 ? 56 : 47); + if (sext != 0 && sext != -1) { + env->error_code = 0; ++ // XXX: or EXCP0C_STACK for SP/BP bassed error + cs->exception_index = EXCP0D_GPF; + return 1; + } +``` + +Relevant excerpt from the Intel SDM: + +> **6.15 EXCEPTION AND INTERRUPT REFERENCE** +> [...] +> **Interrupt 12—Stack Fault Exception (#SS)** +> [...] +> - A canonical violation is detected in 64-bit mode during an operation that reference memory using the stack pointer register containing a non-canonical memory address. + +Please note the lack of mentioning the base pointer register, but tests on real hardware show it's subject to this as well. + +The AMD manual is more precise about that: +> **8.2.13 #SS—Stack Exception (Vector 12)** +> An #SS exception can occur in the following situations: +> - Implied stack references in which the stack address is not in canonical form. Implied stack references include all push and pop instructions, and any instruction using RSP or RBP as a base register +> [...] + +It explicitly mentions "any instruction using RSP or RBP as a base register". diff --git a/results/classifier/gemma3:12b/hypervisor/928676 b/results/classifier/gemma3:12b/hypervisor/928676 new file mode 100644 index 00000000..3c01a0ff --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/928676 @@ -0,0 +1,26 @@ + +QEMU does not support Westmere (Intel Xeon) CPU model + +Setting the CPU model to Westmere (Intel Xeon server CPU) is not possible. + +libvirt uses 'core2duo' as fallback: +https://bugzilla.redhat.com/show_bug.cgi?id=708927 + + +$ qemu -cpu ? +x86 [n270] +x86 [athlon] +x86 [pentium3] +x86 [pentium2] +x86 [pentium] +x86 [486] +x86 [coreduo] +x86 [kvm32] +x86 [qemu32] +x86 [kvm64] +x86 [core2duo] +x86 [phenom] +x86 [qemu64] + +$ qemu --version +QEMU emulator version 1.0 (Debian 1.0+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/931 b/results/classifier/gemma3:12b/hypervisor/931 new file mode 100644 index 00000000..252d21d6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/931 @@ -0,0 +1,2 @@ + +Create GitLab 7.1 milestone diff --git a/results/classifier/gemma3:12b/hypervisor/932 b/results/classifier/gemma3:12b/hypervisor/932 new file mode 100644 index 00000000..fbd84435 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/932 @@ -0,0 +1,15 @@ + +Snapshot created with 6.2.0 cannot be loaded with 7.0.0-rc1 +Description of problem: +Loading the snapshot will fail with: + +```` +qemu-system-x86_64: Missing section footer for 0000:00:01.3/piix4_pm +qemu-system-x86_64: Error -22 while loading VM state +```` +Steps to reproduce: +1. Start VM with `6.2.0`. +2. Create a snapshot `takenwith620` with `snapshot-save` QMP command. +3. Stop VM and try to load snapshot with `v7.0.0-rc1`. +Additional information: +Bisecting led to `5ead62185d ("memory: Make memory_region_is_mapped() succeed when mapped via an alias")`, but reverting that alone wasn't enough, so I continued and got to `7c0fa8dff8 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)")`. Only reverting both seems to fix the issue. diff --git a/results/classifier/gemma3:12b/hypervisor/934 b/results/classifier/gemma3:12b/hypervisor/934 new file mode 100644 index 00000000..92b98d36 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/934 @@ -0,0 +1,46 @@ + +VM execution fails for tianocore edk2 ovmf uefi based image on windows whpx +Description of problem: +Cannot do a UEFI tianocore boot of image with linux installation. + +I think the BIOS/UEFI/firmware when run inside a virtual-machine should be oblivious to the type of hypervisor, just probe and enable the emulated hardware. Maybe WHPX is not enabling pflash devices properly. + +My goal is to create a 40Gb fedora linux image with a on-image UEFI boot sequence that I can +1. native boot using ventoy (works) +2. boot using kvm/qemu in linux (works) +3. boot using whpx/qemu in windows (no success yet) + +My original sequence of steps to reproduce was. +1. Under Linux, in qemu-vm, create a bootable linux image by installing from the fedora livecd installer +2. Confirm qemu-VM/fedora installation/UEFI boot works fine under Linux/kvm/qemu. One can see tianocore logo booting up. +3. reboot to windows +4. attempt to boot with analogous windows qemu command. confirm boot failure and error message +5. remove ```-accel whpx``` and rerun, confirm boot succeeds with tianocore image, albeit un-accelarated + +It turns out the image creation is not required. + +The below works under linux +``` +XDG_RUNTIME_DIR=/run/user/1000 qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/OVMF_VARS.fd" -drive "index=2,format=raw,file=/vol/15KJ_Images/transcend/m02_lnx.raw.img.vtoy" -device "virtio-vga-gl" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait +``` +The below does not work under windows +``` +qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd" -drive "index=1,if=pflash,format=raw,file=E:/vstorage/OVMF_VARS.fd" -drive "index=2,if=virtio,media=disk,format=raw,file=H:\m01_lnx.raw.img" -drive "index=3,if=virtio,media=disk,format=raw,file=H:\gkpics01.raw.img" -drive "index=4,if=virtio,media=disk,format=vhdx,file=E:\test\sgdata.vhdx" -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15 -device virtio-net,netdev=vmnic1 -qmp "tcp:127.0.0.1:5955,server,nowait" +: +Windows Hypervisor Platform accelerator is operational +qemu-system-x86_64: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 +qemu-system-x86_64: WHPX: Failed to exec a virtual processor +``` + +The image does boot if one removes the hardware hypervisor argument ```-accel whpx``` +Steps to reproduce: +The full qemu command with disk images is not required. Just the accel whpx and the pflash devices are sufficient. +1. Confirm that the VM does not execute with the command +``` +qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -boot c -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd" +``` +2. Confirm that the VM does execute and tianocore logo shoes up when ```-accel whpx ``` is removed. +Additional information: +- In the planned changes of Fedora 37, going forward, fedora installer will no longer support installing fresh to machines with legacy BIOS and will necessarily require UEFI boot. This means that there is urgency in allowing this mode of booting. + - https://fedoraproject.org/wiki/Releases/37/ChangeSet + - https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS diff --git a/results/classifier/gemma3:12b/hypervisor/94 b/results/classifier/gemma3:12b/hypervisor/94 new file mode 100644 index 00000000..80cbbcaf --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/94 @@ -0,0 +1,2 @@ + +MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction diff --git a/results/classifier/gemma3:12b/hypervisor/963 b/results/classifier/gemma3:12b/hypervisor/963 new file mode 100644 index 00000000..7ca8f99a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/963 @@ -0,0 +1,2 @@ + +qemu-7.0.0-rc2/migration/ram.c:1292: possible wrong operator ? diff --git a/results/classifier/gemma3:12b/hypervisor/974958 b/results/classifier/gemma3:12b/hypervisor/974958 new file mode 100644 index 00000000..b8366e67 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/974958 @@ -0,0 +1,11 @@ + +It dumps when following this tutorial on hello world os + +http://mikeos.berlios.de/write-your-own-os.html + + +Following the steps, + +it works on ubuntu, + +but on osx, it ALWAYS dumps. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/975 b/results/classifier/gemma3:12b/hypervisor/975 new file mode 100644 index 00000000..e95f2285 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/975 @@ -0,0 +1,39 @@ + +LXD with QEMU 6.2.0 (and 7.0.0-rc3) breaks during stateful migration +Description of problem: + +Steps to reproduce: +``` +sudo snap install --lxd +sudo lxd init --auto +lxc init images:ubuntu/20.04/cloud v1 --vm +Creating v1 +lxc config device override v1 root size.state=2GiB +Device root overridden for v1 +lxc config set v1 migration.stateful=true +lxc start v1 +sleep 10 +lxc exec v1 -- uptime + 22:05:54 up 0 min, 0 users, load average: 0.07, 0.02, 0.00 +lxc snapshot v1 --stateful +Error: Migration call failed +lxc snapshot v1 --stateful +Error: Monitor is disconnected +``` + +The first attempt at `lxc snapshot v1 --stateful` caused this in the `lxc info v1 --show-log` log output: + +``` +qemu-system-x86_64: qemu_savevm_state_complete_precopy_non_iterable: bdrv_inactivate_all() failed (-1) +``` + +The second attempt caused this: + +``` +qemu-system-x86_64: ../block.c:6757: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +``` + +Which crashed QEMU completely and caused the VM to die. +Nothing relevant showed up in dmesg, so this wasn't caused by an obvious seccomp or apparmor policy issue. +Additional information: +Originally reported by Stephane Graber at https://github.com/lxc/lxd/issues/9875 diff --git a/results/classifier/gemma3:12b/hypervisor/990 b/results/classifier/gemma3:12b/hypervisor/990 new file mode 100644 index 00000000..93f234c0 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/990 @@ -0,0 +1,2 @@ + +support for vIOMMU and vSR-IOV together in L1 as virtual machine diff --git a/results/classifier/gemma3:12b/hypervisor/993 b/results/classifier/gemma3:12b/hypervisor/993 new file mode 100644 index 00000000..0e290e1a --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/993 @@ -0,0 +1,82 @@ + +Invalid opcode vzeroupper +Description of problem: +Got many invalid opcode error with Fedora 36 +See fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=2076410 + +Crash stack and disassemble. +``` +Downloading separate debug info for /lib64/liblzma.so.5... +Downloading separate debug info for /home/penghuang/Sources/system-supplied DSO at 0x7fff30f55000... +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Core was generated by `flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo'. +Program terminated with signal SIGILL, Illegal instruction. +#0 0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30 +[Current thread is 1 (Thread 0x7f8972ada640 (LWP 5083))] +(gdb) bt +#0 0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30 +#1 0x00007f89783bf042 in x86_sha512_update (ctx=0x7f8972ad9090, length=128, data=0x7f8972ad8f90 '\\' <repeats 128 times>, "@\255") + at sha-x86-ssse3.c:215 +#2 0x00007f897810879b in nettle_hmac_set_key (outer=<optimized out>, inner=0x7f8972ad9168, state=<optimized out>, + hash=0x7f897848b6c0 <x86_sha384>, key_length=0, key=0x7f89783ff943 "") at /usr/src/debug/nettle-3.7.3-3.fc36.x86_64/hmac.c:83 +#3 0x00007f89783bce3a in wrap_x86_hmac_fast (algo=<optimized out>, nonce=<optimized out>, nonce_size=<optimized out>, key=0x7f89783ff943, + key_size=0, text=0x7f8972ad9430, text_size=48, digest=0x55a79d80b948) at hmac-x86-ssse3.c:294 +#4 0x00007f89782d4b57 in _gnutls_mac_fast (algorithm=GNUTLS_MAC_SHA384, key=0x7f89783ff943, keylen=0, text=0x7f8972ad9430, textlen=48, + digest=0x55a79d80b948) at hash_int.c:167 +#5 0x00007f89782f524d in gnutls_hmac_fast (algorithm=GNUTLS_MAC_SHA384, key=key@entry=0x7f89783ff943, keylen=keylen@entry=0, + ptext=0x7f8972ad9430, ptext_len=ptext_len@entry=48, digest=digest@entry=0x55a79d80b948) at crypto-api.c:640 +#6 0x00007f897830d2ff in _tls13_init_secret2 (prf=0x7f897848f888 <hash_algorithms+168>, psk=<optimized out>, psk@entry=0x0, psk_size=48, + psk_size@entry=0, out=out@entry=0x55a79d80b948) at secrets.c:59 +#7 0x00007f897830d3d0 in _tls13_init_secret (session=session@entry=0x55a79d80a1c0, psk=psk@entry=0x0, psk_size=psk_size@entry=0) at secrets.c:35 +#8 0x00007f89782c66c0 in read_server_hello (datalen=<optimized out>, data=<optimized out>, session=0x55a79d80a1c0) at handshake.c:2097 +#9 _gnutls_recv_handshake (session=session@entry=0x55a79d80a1c0, type=type@entry=GNUTLS_HANDSHAKE_SERVER_HELLO, optional=optional@entry=0, + buf=buf@entry=0x0) at handshake.c:1656 +#10 0x00007f89782c8dbb in handshake_client (session=0x55a79d80a1c0) at handshake.c:3072 +#11 gnutls_handshake (session=0x55a79d80a1c0) at handshake.c:2871 +#12 0x00007f89784a694f in g_tls_connection_gnutls_handshake_thread_handshake (tls=0x55a79d80c250, timeout=<optimized out>, + cancellable=<optimized out>, error=0x7f8972ad9b10) at ../tls/gnutls/gtlsconnection-gnutls.c:968 +#13 0x00007f89784a8942 in handshake_thread (task=0x7f8968007ec0, object=object@entry=0x55a79d80c250, task_data=task_data@entry=0x55a79d766e60, + cancellable=cancellable@entry=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1564 +#14 0x00007f89784a8c02 in async_handshake_thread (task=<optimized out>, object=0x55a79d80c250, task_data=0x55a79d766e60, + cancellable=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1848 +#15 0x00007f89882dbaf3 in g_task_thread_pool_thread (thread_data=0x7f8968007ec0, pool_data=<optimized out>) at ../gio/gtask.c:1441 +#16 0x00007f8988111b72 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354 +#17 0x00007f898810f172 in g_thread_proxy (data=0x55a79d7e1360) at ../glib/gthread.c:827 +#18 0x00007f8987efdcc7 in start_thread (arg=<optimized out>) at pthread_create.c:442 +#19 0x00007f8987f82e00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +(gdb) +(gdb) disassemble +Dump of assembler code for function sha512_block_data_order_avx2: + 0x00007f89783cbe00 <+0>: mov %rsp,%rax + 0x00007f89783cbe03 <+3>: push %rbx + 0x00007f89783cbe04 <+4>: push %rbp + 0x00007f89783cbe05 <+5>: push %r12 + 0x00007f89783cbe07 <+7>: push %r13 + 0x00007f89783cbe09 <+9>: push %r14 + 0x00007f89783cbe0b <+11>: push %r15 + 0x00007f89783cbe0d <+13>: sub $0x520,%rsp + 0x00007f89783cbe14 <+20>: shl $0x4,%rdx + 0x00007f89783cbe18 <+24>: and $0xfffffffffffff800,%rsp + 0x00007f89783cbe1f <+31>: lea (%rsi,%rdx,8),%rdx + 0x00007f89783cbe23 <+35>: add $0x480,%rsp + 0x00007f89783cbe2a <+42>: mov %rdi,0x80(%rsp) + 0x00007f89783cbe32 <+50>: mov %rsi,0x88(%rsp) + 0x00007f89783cbe3a <+58>: mov %rdx,0x90(%rsp) + 0x00007f89783cbe42 <+66>: mov %rax,0x98(%rsp) +=> 0x00007f89783cbe4a <+74>: vzeroupper + 0x00007f89783cbe4d <+77>: sub $0xffffffffffffff80,%rsi + 0x00007f89783cbe51 <+81>: mov (%rdi),%rax + 0x00007f89783cbe54 <+84>: mov %rsi,%r12 + 0x00007f89783cbe57 <+87>: mov 0x8(%rdi),%rbx + 0x00007f89783cbe5b <+91>: cmp %rdx,%rsi + 0x00007f89783cbe5e <+94>: mov 0x10(%rdi),%rcx + 0x00007f89783cbe62 <+98>: cmove %rsp,%r12 + 0x00007f89783cbe66 <+102>: mov 0x18(%rdi),%rdx + 0x00007f89783cbe6a <+106>: mov 0x20(%rdi),%r8 + 0x00007f89783cbe6e <+110>: mov 0x28(%rdi),%r9 + 0x00007f89783cbe72 <+114>: mov 0x30(%rdi),%r10 + 0x00007f89783cbe76 <+118>: mov 0x38(%rdi),%r11 + 0x00007f89783cbe7a <+122>: jmp 0x7f89783cbe80 <sha512_block_data_order_avx2+128> + 0x00007f89783cbe7c <+124>: nopl 0x0(%rax) +``` diff --git a/results/classifier/gemma3:12b/hypervisor/994 b/results/classifier/gemma3:12b/hypervisor/994 new file mode 100644 index 00000000..9bdedccc --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/994 @@ -0,0 +1,6 @@ + +7.0.0-rc4 doesn't launch on Windows +Description of problem: +The program immediately exits, without even printing version information (or anything). +Steps to reproduce: +1. Run the command above |