diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/gemma3:12b/kvm/188 | 2 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/kvm/1880507 | 4 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/kvm/1881231 | 32 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/kvm/1884095 | 24 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/kvm/1885175 | 53 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/kvm/1886318 | 40 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/kvm/1888165 | 15 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/kvm/1888971 | 14 |
8 files changed, 184 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/kvm/188 b/results/classifier/gemma3:12b/kvm/188 new file mode 100644 index 00000000..318936dc --- /dev/null +++ b/results/classifier/gemma3:12b/kvm/188 @@ -0,0 +1,2 @@ + +savevm with hax saves wrong register state diff --git a/results/classifier/gemma3:12b/kvm/1880507 b/results/classifier/gemma3:12b/kvm/1880507 new file mode 100644 index 00000000..bfbcb5ae --- /dev/null +++ b/results/classifier/gemma3:12b/kvm/1880507 @@ -0,0 +1,4 @@ + +VMM from Ubuntu 20.04 does not show the memory consumption + +KVM host system: Ubuntu 18.04 and 20.04, guest machines: Windows and Ubuntu. Management through Ubuntu 20.04, vmm does not show RAM consumption for Windows guest systems (Win7, Win2008R2), for Ubuntu values are shown. The error is not observed in Ubuntu 18.04/vmm. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/kvm/1881231 b/results/classifier/gemma3:12b/kvm/1881231 new file mode 100644 index 00000000..ba97c8a9 --- /dev/null +++ b/results/classifier/gemma3:12b/kvm/1881231 @@ -0,0 +1,32 @@ + +colo: Can not recover colo after svm failover twice + +Hi Expert, +x-blockdev-change met some error, during testing colo + +Host os: +CentOS Linux release 7.6.1810 (Core) + +Reproduce steps: +1. create colo vm following https://github.com/qemu/qemu/blob/master/docs/COLO-FT.txt +2. kill secondary vm and remove the nbd child from the quorum to wait for recover + type those commands on primary vm console: + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} + { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del replication0'}} + { 'execute': 'x-colo-lost-heartbeat'} +3. recover colo +4. kill secondary vm again after recover colo and type same commands as step 2: + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} + { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del replication0'}} + { 'execute': 'x-colo-lost-heartbeat'} + but the first command got error + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} +{"error": {"class": "GenericError", "desc": "Node 'colo-disk0' does not have child 'children.1'"}} + +according to https://www.qemu.org/docs/master/qemu-qmp-ref.html +Command: x-blockdev-change +Dynamically reconfigure the block driver state graph. It can be used to add, remove, insert or replace a graph node. Currently only the Quorum driver implements this feature to add or remove its child. This is useful to fix a broken quorum child. + +It seems x-blockdev-change not worked as expected. + +Thanks. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/kvm/1884095 b/results/classifier/gemma3:12b/kvm/1884095 new file mode 100644 index 00000000..4e2030b8 --- /dev/null +++ b/results/classifier/gemma3:12b/kvm/1884095 @@ -0,0 +1,24 @@ + +QEMU not sufficiently focused on qEMUlation, with resulting holes in TCG emulation coverage + +It seems that QEMU has stopped emphasizing the EMU part of the name, and is too much focused on virtualization. + +My interest is at running legacy operating systems, and as such, they must run on foreign CPU platforms. m68 on intel, intel on ARM, etc. +Time doesn't stand still, and reliance on KVM and similar x86-on-x86 tricks, which allow the delegation of certain CPU features to the host CPU is going to not work going forward. + +If the rumored transition of Apple to ARM is going to take place, people will want to e.g. emulate for testing or legacy purposes a variety of operating systems, incl. NeXTSTEP, Windows, earlier versions of MacOS on ARM Macs. + +Testing that scenario, i.e. macOS on an ARM board with the lowest possible CPU capable of running modern macOS, results in these problems (and of course utter failure achieving the goal): + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +And this is emulating a lowly Penryn CPU with the required CPU flags for macOS: +-cpu Penryn,vendor=GenuineIntel,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc + +Attempting to emulate a more feature laden intel CPU results in even more issues. + +I would propose that no CPU should be considered supported unless it can be fully handled by TCG on a non-native host. KVM, native-on-native etc. are nice to have, but peripheral to qEMUlation when it boils down to it. At the very least, there should be a CLEAR distinction which CPUs require KVM to be used, and which can be fully emulated. It should not require wasting an afternoon to figure out that an emulation attempt is futile because TCG lacks essential functionality. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/kvm/1885175 b/results/classifier/gemma3:12b/kvm/1885175 new file mode 100644 index 00000000..dc5eb2b6 --- /dev/null +++ b/results/classifier/gemma3:12b/kvm/1885175 @@ -0,0 +1,53 @@ + +memory.c range assertion hit at full invalidating + +I am able to hit this assertion when a Red Hat 7 guest virtio_net device raises an "Invalidation" of all the TLB entries. This happens in the guest's startup if 'intel_iommu=on' argument is passed to the guest kernel and right IOMMU/ATS devices are declared in qemu's command line. + +Command line: /home/qemu/x86_64-softmmu/qemu-system-x86_64 -name guest=rhel7-test,debug-threads=on -machine pc-q35-5.1,accel=kvm,usb=off,dump-guest-core=off,kernel_irqchip=split -cpu Broadwell,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,arch-capabilities=on,xsaveopt=on,pdpe1gb=on,abm=on,skip-l1dfl-vmentry=on,rtm=on,hle=on -m 8096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid d022ecbf-679e-4755-87ce-eb87fc5bbc5d -display none -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device intel-iommu,intremap=on,device-iotlb=on -device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 -device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 -device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 -device pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 -device pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 -device pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 -device pcie-root-port,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x1.0x6 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -drive file=/home/virtio-test2.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,id=hostnet0,vhost=on,vhostforce=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0d:1d:f2,bus=pci.1,addr=0x0,iommu_platform=on,ats=on -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 -s -msg timestamp=on + +Full backtrace: + +#0 0x00007ffff521370f in raise () at /lib64/libc.so.6 +#1 0x00007ffff51fdb25 in abort () at /lib64/libc.so.6 +#2 0x00007ffff51fd9f9 in _nl_load_domain.cold.0 () at /lib64/libc.so.6 +#3 0x00007ffff520bcc6 in .annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x0000555555888171 in memory_region_notify_one (notifier=0x7ffde05dfde8, entry=0x7ffde5dfe200) at /home/qemu/memory.c:1918 +#5 0x0000555555888247 in memory_region_notify_iommu (iommu_mr=0x555556f6c0b0, iommu_idx=0, entry=...) at /home/qemu/memory.c:1941 +#6 0x0000555555951c8d in vtd_process_device_iotlb_desc (s=0x555557609000, inv_desc=0x7ffde5dfe2d0) + at /home/qemu/hw/i386/intel_iommu.c:2468 +#7 0x0000555555951e6a in vtd_process_inv_desc (s=0x555557609000) at /home/qemu/hw/i386/intel_iommu.c:2531 +#8 0x0000555555951fa5 in vtd_fetch_inv_desc (s=0x555557609000) at /home/qemu/hw/i386/intel_iommu.c:2563 +#9 0x00005555559520e5 in vtd_handle_iqt_write (s=0x555557609000) at /home/qemu/hw/i386/intel_iommu.c:2590 +#10 0x0000555555952b45 in vtd_mem_write (opaque=0x555557609000, addr=136, val=2688, size=4) at /home/qemu/hw/i386/intel_iommu.c:2837 +#11 0x0000555555883e17 in memory_region_write_accessor + (mr=0x555557609330, addr=136, value=0x7ffde5dfe478, size=4, shift=0, mask=4294967295, attrs=...) at /home/qemu/memory.c:483 +#12 0x000055555588401d in access_with_adjusted_size + (addr=136, value=0x7ffde5dfe478, size=4, access_size_min=4, access_size_max=8, access_fn= + 0x555555883d38 <memory_region_write_accessor>, mr=0x555557609330, attrs=...) at /home/qemu/memory.c:544 +#13 0x0000555555886f37 in memory_region_dispatch_write (mr=0x555557609330, addr=136, data=2688, op=MO_32, attrs=...) + at /home/qemu/memory.c:1476 +#14 0x0000555555827a03 in flatview_write_continue + (fv=0x7ffde00935d0, addr=4275634312, attrs=..., ptr=0x7ffff7ff0028, len=4, addr1=136, l=4, mr=0x555557609330) at /home/qemu/exec.c:3146 +#15 0x0000555555827b48 in flatview_write (fv=0x7ffde00935d0, addr=4275634312, attrs=..., buf=0x7ffff7ff0028, len=4) + at /home/qemu/exec.c:3186 +#16 0x0000555555827e9d in address_space_write + (as=0x5555567ca640 <address_space_memory>, addr=4275634312, attrs=..., buf=0x7ffff7ff0028, len=4) at /home/qemu/exec.c:3277 +#17 0x0000555555827f0a in address_space_rw + (as=0x5555567ca640 <address_space_memory>, addr=4275634312, attrs=..., buf=0x7ffff7ff0028, len=4, is_write=true) + at /home/qemu/exec.c:3287 +#18 0x000055555589b633 in kvm_cpu_exec (cpu=0x555556b65640) at /home/qemu/accel/kvm/kvm-all.c:2511 +#19 0x0000555555876ba8 in qemu_kvm_cpu_thread_fn (arg=0x555556b65640) at /home/qemu/cpus.c:1284 +#20 0x0000555555dafff1 in qemu_thread_start (args=0x555556b8c3b0) at util/qemu-thread-posix.c:521 +#21 0x00007ffff55a62de in start_thread () at /lib64/libpthread.so.0 +#22 0x00007ffff52d7e83 in clone () at /lib64/libc.so.6 + +-- + +If we examinate *entry in frame 4 of backtrace: +*entry = {target_as = 0x555556f6c050, iova = 0x0, translated_addr = 0x0, addr_mask = 0xffffffffffffffff, perm = 0x0} + +Which (I think) tries to invalidate all the TLB registers of the device. + +Just deleting that assert is enough for the VM to start and communicate using IOMMU, but maybe a better alternative is possible. We could move it to the caller functions in other cases than IOMMU invalidation, or make it conditional only if not invalidating. + +Guest kernel version: kernel-3.10.0-1136.el7 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/kvm/1886318 b/results/classifier/gemma3:12b/kvm/1886318 new file mode 100644 index 00000000..e3226ddb --- /dev/null +++ b/results/classifier/gemma3:12b/kvm/1886318 @@ -0,0 +1,40 @@ + +Qemu after v5.0.0 breaks macos guests + +The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. + +So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. + +Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: + +qemu-system-x86_64 \ + -enable-kvm \ + -m 4G \ + -machine q35,accel=kvm \ + -smp 4,sockets=1,cores=2,threads=2 \ + -cpu +Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc +\ + -device +isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" +\ + -smbios type=2 \ + -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ + -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ + -vga qxl \ + -device ich9-ahci,id=sata \ + -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ + -device ide-hd,bus=sata.2,drive=ESP \ + -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ + -device ide-hd,bus=sata.3,drive=InstallMedia \ + -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ + -device ide-hd,bus=sata.4,drive=SystemDisk \ + -usb -device usb-kbd -device usb-mouse + +Perhaps something has changed in Penryn support recently, as that's required for macos? + +See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 + +Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. + +See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/kvm/1888165 b/results/classifier/gemma3:12b/kvm/1888165 new file mode 100644 index 00000000..d8759ff6 --- /dev/null +++ b/results/classifier/gemma3:12b/kvm/1888165 @@ -0,0 +1,15 @@ + +loopz/loopnz clearing previous instruction's modified flags on cx -> 0 + +If you run QBasic in qemu, printing a double-type single-digit number will print an extra decimal point (e.g. PRINT CDBL(3) prints "3.") that does not appear when running on a real CPU (or on qemu with -enable-kvm). I tracked this down to the state of the status flags after a loopnz instruction. + +After executing a sequence like this in qemu: + + mov bx,1 + mov cx,1 + dec bx ; sets Z bit in flags +A: loopnz A ; should not modify flags + +Z is incorrectly clear afterwards. loopz does the same thing (but not plain loop). Interestingly, inserting pushf+popf after dec results in Z set, so loopnz/loopz does not always clear Z itself but is rather interfering with the previous instruction's flag setting. + +Version 5.1.0-rc0, x86-64 host. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/kvm/1888971 b/results/classifier/gemma3:12b/kvm/1888971 new file mode 100644 index 00000000..7cc90f00 --- /dev/null +++ b/results/classifier/gemma3:12b/kvm/1888971 @@ -0,0 +1,14 @@ + +SMI trigger causes hang with multiple cores + +When using qemu , SMI trigger causes hand/reboot under following conditions: + +1. No KVM but there are more than 1 threads (-smp > 1) +2. When using KVM. + +Info: +qemu-system-x86_64 --version +QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.29) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +SMI trigger was done by writing 0x00 in IO port 0xB2. \ No newline at end of file |