diff options
Diffstat (limited to 'results/classifier/deepseek-2/output/hypervisor')
654 files changed, 13902 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2/output/hypervisor/1002 b/results/classifier/deepseek-2/output/hypervisor/1002 new file mode 100644 index 000000000..d700efb30 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1002 @@ -0,0 +1,2 @@ + +qemu-system-aarch64: Synchronous Exception with smp > 1 (on M1 running Asahi Linux with KVM) diff --git a/results/classifier/deepseek-2/output/hypervisor/1003 b/results/classifier/deepseek-2/output/hypervisor/1003 new file mode 100644 index 000000000..8e76c5628 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1003 @@ -0,0 +1,22 @@ + +"Cannot allocate memory" when boots a VM > 1026GB memory with -accel kvm +Description of problem: +I can boot an empty VM using command `qemu-system-x86_64 -m 1026G -accel kvm -vnc :1` or `qemu-system-x86_64 -m 8T -vnc :1` + +But when I use `qemu-system-x86_64 -m 1027G -accel kvm -vnc :1`, it will not boot: + +``` +root@debian11:~# qemu-system-x86_64 -m 1027G -accel kvm -vnc :1 +qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=1, start=0x100000000, size=0x10000000000: Cannot allocate memory +kvm_set_phys_mem: error registering slot: Cannot allocate memory +Aborted +``` + +Which means, with `-accel kvm`, it only can boot a VM which memory <= 1026G, but without these args, it can boot whatever you want. +Steps to reproduce: +1. sysctl vm.overcommit_memory=1 # enable overcommit first +2. qemu-system-x86_64 -m 1027G -accel kvm -vnc :1 +Additional information: +The qemu I use is compiled from the latest source, not the package provided by debian. + +Hardware is `PowerEdge R630` with `E5-2630 v4` * 2, 128G physical RAM. diff --git a/results/classifier/deepseek-2/output/hypervisor/1006 b/results/classifier/deepseek-2/output/hypervisor/1006 new file mode 100644 index 000000000..6426578fc --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1006 @@ -0,0 +1,4 @@ + +qga: add get disk stats of guest interface +Additional information: +just for linux diff --git a/results/classifier/deepseek-2/output/hypervisor/1008 b/results/classifier/deepseek-2/output/hypervisor/1008 new file mode 100644 index 000000000..18d4e83ec --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1008 @@ -0,0 +1,21 @@ + +nested virtualisation with old host kernel, qemu 7.0.0 broken +Description of problem: +``` +$ qemu-system-x86_64 -enable-kvm -nographic +qemu-system-x86_64: error: failed to set MSR 0xc0000104 to 0x100000000 +qemu-system-x86_64: ../target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +Aborted (core dumped) + +$ +``` +Steps to reproduce: +1. (hardware) Host 1 running kernel 5.10 with nested kvm enabled +2. (virtual) Host 2, with qemu 7.0.0 installed +3. In the inner/virtual host, run: `qemu-system-x86 -enable-kvm -nographic` +Additional information: +It is fixed by using either a more up-to-date kernel version on the hardware/outer host (5.17.x for example), or by reverting to qemu 6.2.0 in the virtual/inner host. + +I have also reproduced this with latest qemu master, commit 731340813fdb4cb8339edb8630e3f923b7d987ec. + +**Reverting commit 3e4546d5bd38a1e98d4bd2de48631abf0398a3a2 also fixes the issue.** diff --git a/results/classifier/deepseek-2/output/hypervisor/101 b/results/classifier/deepseek-2/output/hypervisor/101 new file mode 100644 index 000000000..f577255fe --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/101 @@ -0,0 +1,2 @@ + +Running a virtual machine on a Haswell system produces machine check events diff --git a/results/classifier/deepseek-2/output/hypervisor/1011 b/results/classifier/deepseek-2/output/hypervisor/1011 new file mode 100644 index 000000000..f1abe1c13 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1013714 b/results/classifier/deepseek-2/output/hypervisor/1013714 new file mode 100644 index 000000000..75342da28 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1013714 @@ -0,0 +1,17 @@ + +Data corruption after block migration (LV->LV) + +We quite frequently use the live block migration feature to move VM's between nodes without downtime. These sometimes result in data corruption on the receiving end. It only happens if the VM is actually doing I/O (doesn't have to be all that much to trigger the issue). + +We use logical volumes and each VM has two disks. We use cache=none for all VM disks. + +All guests use virtio (a mix of various Linux distro's and Windows 2008R2). + +We currently have two stacks in use and have seen the issue on both of them: + +Fedora - qemu-kvm 0.13 +Scientific Linux 6.2 (RHEL derived) - qemu-kvm package 0.12.1.2 + +Even though we don't run the most recent versions of KVM I highly suspect this issue is still unreported and that filing a bug is therefore appropriate. (There doesn't seem to be any similar bug report in launchpad or RedHat's bugzilla and nothing related in change logs, release notes and git commit logs.) + +I have no idea where to look or where to start debugging this issue, but if there is any way I can provide useful debug information please let me know. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1031 b/results/classifier/deepseek-2/output/hypervisor/1031 new file mode 100644 index 000000000..66e28a108 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1034423 b/results/classifier/deepseek-2/output/hypervisor/1034423 new file mode 100644 index 000000000..669ba1e84 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1034423 @@ -0,0 +1,61 @@ + +Guests running OpenIndiana (and relatives) fail to boot on AMD hardware + +First observed with OpenSolaris 2009.06, and also applies to the latest OpenIndiana release. + +Version: qemu-kvm 1.1.1 + +Hardware: + +2 x AMD Opteron 6128 8-core processors, 64GB RAM. + +These guests boot on equivalent Intel hardware. + +To reproduce: + +qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-151a5-live-x86.iso -boot order=dc + +I've tested with "-vga std" and various different emulated CPU types, to no effect. + +What happens: + +GRUB loads, and offers multiple boot options, but none work. Some kind of kernel panic flies by very fast before restarting the VM, and careful use of the screenshot button reveals that it reads as follows: + +panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault) rp=fec2b48c add r=0 + +#df Double fault +pid=0, pc=0xault +pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202 +cr0: 80050011<pg,wp,et,pe> cr4:b8<pge,pae,pse,de> +cr2: 0cr3: ae2f000 + gs: 1b0 fs: 0 es: 160 ds: 160 + edi: 0 esi: 0 ebp: 0 esp: fec2b4c4 + ebx: c0010015 edx: 0 ecx: 0 eax: fec40400 + trp: 8 err: 0 eip: fe800377 cs: 158 + efl: 202 usp: fec40090 ss: 160 +tss.tss_link: 0x0 +tss.tss_esp0: 0x0 +tss.tss_ss0: 0x160 +tss.tss_esp1: 0x0 +tss.tss_ss1: 0x0 +tss.tss esp2: 0x0 +tss.tss_ss2: 0x0 +tss.tss_cr3: 0xae2f000 +tss.tss_eip: 0xfec40400 +tss.tss_eflags: 0x202 +tss.tss_eax: 0xfec40400 +tss.tss_ebx: 0xc0010015 +tss.tss_ecx: 0xc0010000 +tss.tss_edx: 0x0 +tss.tss_esp: 0xfec40090 + +Warning - stack not written to the dumpbuf +fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0) +fec2b478 unix:trap+12fa (fec2b48c, 0, 0) +fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0) + +If there's any more, I haven't managed to catch it. + +Solaris 11 does not seem to suffer from the same issue, although the first message that appears at boot (after the version info) is "trap: Unkown trap type 8 in user mode". Could be related? + +As always, thanks in advance and please let me know if I can help to test, or provide any more information. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1035 b/results/classifier/deepseek-2/output/hypervisor/1035 new file mode 100644 index 000000000..6f8d34129 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1035 @@ -0,0 +1,17 @@ + +Hyper-V on KVM does not work on AMD CPUs +Description of problem: +Can not enable hytper-v on KVM on AMD 3970x +``` +[ 3743.647780] SVM: kvm [17094]: vcpu0, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.014046] SVM: kvm [17094]: vcpu1, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.016101] SVM: kvm [17094]: vcpu2, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.018011] SVM: kvm [17094]: vcpu3, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.020032] SVM: kvm [17094]: vcpu4, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.021834] SVM: kvm [17094]: vcpu5, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.023644] SVM: kvm [17094]: vcpu6, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.025478] SVM: kvm [17094]: vcpu7, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +``` +Additional information: +Related issue: +https://bugzilla.kernel.org/show_bug.cgi?id=203477 diff --git a/results/classifier/deepseek-2/output/hypervisor/1038070 b/results/classifier/deepseek-2/output/hypervisor/1038070 new file mode 100644 index 000000000..d7b0af808 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1038070 @@ -0,0 +1,28 @@ + +> qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore + +Linux Distro: Gentoo + +Smartcard Activkey doesn't work anymore. I use it without problem till version +qemu-kvm-1.0.1. + +Follow a log extraction: +2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : +internal error Process exited while reading console log output: char device +redirected to /dev/pts/40 +ccid-card-emulated: failed to initialize vcard +qemu-system-x86_64: -device +ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +'ccid-card-emulated' could not be initialized + +2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : +internal error Process exited while reading console log output: char device +redirected to /dev/pts/40 +ccid-card-emulated: failed to initialize vcard +qemu-system-x86_64: -device +ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +'ccid-card-emulated' could not be initialized + +If you need any other info please tell me. + +I've tried with git version with same problem. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1040 b/results/classifier/deepseek-2/output/hypervisor/1040 new file mode 100644 index 000000000..bdc9f39ea --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1043 b/results/classifier/deepseek-2/output/hypervisor/1043 new file mode 100644 index 000000000..a87eb9a55 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1046 b/results/classifier/deepseek-2/output/hypervisor/1046 new file mode 100644 index 000000000..98e356734 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1046 @@ -0,0 +1,13 @@ + +Using more than 2G of RAM on armv7l guest with RPI4 +Description of problem: +I was able to run my armv7l guest on RPI4 8G using qemu 6.2, but on 7.0 it doesn't work: +`qemu-kvm: Addressing limited to 32 bits, but memory exceeds it by 3221225472 bytes`. + +The only reference I found is this issue: https://gitlab.com/qemu-project/qemu/-/issues/903 +Steps to reproduce: +1. `-M virt,highmem=off,gic-version=host,accel=kvm` +2. `-cpu host,aarch64=off` +3. `-m 6G` +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1047 b/results/classifier/deepseek-2/output/hypervisor/1047 new file mode 100644 index 000000000..98b1fb1a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1047 @@ -0,0 +1,105 @@ + +Single stepping Windows 10 bootloader results in Assertion `ret < cpu->num_ases && ret >= 0' failed. +Description of problem: +When I am trying to debug Windows bootloader, I see an assertion error in QEMU when single stepping some instructions in SeaBIOS. + +``` +qemu-system-i386: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed. +``` +Steps to reproduce: +1. Download / construct `w.img`, see above +2. Start QEMU using `./qemu-system-i386 --drive media=disk,file=w.img,format=raw,index=1 -s -S -enable-kvm` +3. Start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0x7c00' --ex c --ex 'si 1000' --ex q` +4. See error message +Additional information: +The GDB script first breaks at 0x7c00, then tries to execute 1000 instructions using single step (`si`). On my machine, after executing around 772 instructions, the assertion error in QEMU happens. +Here is an interactive GDB session on my machine. + +``` +(gdb) hb *0x7c00 +Hardware assisted breakpoint 1 at 0x7c00 +(gdb) c +Continuing. + +Breakpoint 1, 0x00007c00 in ?? () +(gdb) d +Delete all breakpoints? (y or n) y +(gdb) si 770 +0x000f7d7b in ?? () +(gdb) x/10i $eip +=> 0xf7d7b: mov $0x7d85,%ebx + 0xf7d80: out %al,$0xb2 + 0xf7d82: pause + 0xf7d84: hlt + 0xf7d85: mov %bp,%sp + 0xf7d88: jmp 0xf7dd1 + 0xf7d8a: mov %cx,%si + 0xf7d8d: mov $0x1,%ax + 0xf7d91: add %al,(%eax) + 0xf7d93: callw 0x6b66 +(gdb) si +0x000f7d80 in ?? () +(gdb) info reg +eax 0xb5 181 +ecx 0x5678 22136 +edx 0x0 0 +ebx 0x7d85 32133 +esp 0xe96d4 0xe96d4 +ebp 0xfed4 0xfed4 +esi 0xe0346 918342 +edi 0xefd91 982417 +eip 0xf7d80 0xf7d80 +eflags 0x6 [ IOPL=0 PF ] +cs 0x8 8 +ss 0x10 16 +ds 0x10 16 +es 0x10 16 +fs 0x10 16 +gs 0x10 16 +fs_base 0x0 0 +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x11 [ ET PE ] +cr2 0x0 0 +cr3 0x0 [ PDBR=0 PCID=0 ] +cr4 0x0 [ ] +cr8 0x0 0 +efer 0x0 [ ] +... +mxcsr 0x1f80 [ IM DM ZM OM UM PM ] +(gdb) si +0x000f7d82 in ?? () +(gdb) info reg +eax 0xb5 181 +ecx 0x5678 22136 +edx 0x0 0 +ebx 0x7d85 32133 +esp 0xe96d4 0xe96d4 +ebp 0xfed4 0xfed4 +esi 0xe0346 918342 +edi 0xefd91 982417 +eip 0xf7d82 0xf7d82 +eflags 0x6 [ IOPL=0 PF ] +cs 0x8 8 +ss 0x10 16 +ds 0x10 16 +es 0x10 16 +fs 0x10 16 +gs 0x10 16 +fs_base 0x0 0 +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x11 [ ET PE ] +cr2 0x0 0 +cr3 0x0 [ PDBR=0 PCID=0 ] +cr4 0x0 [ ] +cr8 0x0 0 +efer 0x0 [ ] +... +mxcsr 0x1f80 [ IM DM ZM OM UM PM ] +(gdb) si +Remote connection closed +(gdb) +``` + +This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216003>. diff --git a/results/classifier/deepseek-2/output/hypervisor/1057 b/results/classifier/deepseek-2/output/hypervisor/1057 new file mode 100644 index 000000000..975d0b0ba --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1060 b/results/classifier/deepseek-2/output/hypervisor/1060 new file mode 100644 index 000000000..e6f36db4f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1060 @@ -0,0 +1,34 @@ + +RISC-V: mtval/stval is not correctly set to the instruction itself on illegal instructions +Description of problem: +QEMU 7.0 claims to support `stval`/`mtval` for illegal instructions, but `mtval`/`stval` is actually set to `0` +Steps to reproduce: +1. Assemble and link `mtval-illegal.elf`. The code simply sets up a trap handler and generates an illegal instruction exception + +2. Start QEMU with: + + ``` + qemu-system-riscv64 -cpu rv64,h=off -bios mtval-illegal.elf -nographic -icount shift=0 -s -S + ``` + +3. Attach with GDB: + + ``` + gdb mtval-illegal.elf + + # Within GDB + target extended-remote :1234 + break trap + disp $mtval + + # Keep single stepping until breakpoint + stepi + ``` + +4. When control flow reaches `trap`, `mtval` is written with `0` instead of the encoding of `csrw time, x0` (`0xc0101073`) +Additional information: +Writing `0` to `mtval` on a illegal instruction trap is allowed by the specs, but since the [changelog of QEMU 7.0][changelog] says it should be supported, I would consider it a bug. + +[changelog]: https://wiki.qemu.org/ChangeLog/7.0#RISC-V + +I encountered this when trying to figure out why my program worked with QEMU 6 but breaks with QEMU 7. It's more complicated, but in that case I managed to get `mtval` written with neither `0` nor the actual illegal instruction, but a different illegal instruction. I will try gathering up all the dependencies and write down the steps to reproduce if needed and if I find the time. diff --git a/results/classifier/deepseek-2/output/hypervisor/1062 b/results/classifier/deepseek-2/output/hypervisor/1062 new file mode 100644 index 000000000..72f023abf --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1062 @@ -0,0 +1,17 @@ + +AArch64: SCR_EL3.RW behaves incorrectly for CPUs with no AArch32 +Description of problem: +In the ARM DDI 0487G.a, D13-3572, the SCR_EL3.RW bit is defined as RAO/WI if both EL2 and EL1 don't support Aarch32. However, the function `scr_write` in `target/arm/helper.c` does not reflect this behavior, even though it checks for Aarch32 EL1 support. + +This would break this EL3 code, which should run on cpu reset to attempt to return to EL1: +```asm +mov x1, #((1<<0)|(1<<2)|(1<<6)|(1<<7)|(1<<8)|(1<<9)) ; EL1h, DAIF masked +mov SPSR_EL3, x1 +adr x1, 1f +msr ELR_EL3, x1 +eret +1: +; something something +``` +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1065 b/results/classifier/deepseek-2/output/hypervisor/1065 new file mode 100644 index 000000000..59be28698 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1068 b/results/classifier/deepseek-2/output/hypervisor/1068 new file mode 100644 index 000000000..7d82c1e2d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1068 @@ -0,0 +1,12 @@ + +VMs stuck loading Kernel "Freeing unused Kernel image (initmem) memory" with host running Vanilla Kernel >= 5.18.0 +Description of problem: +The VMs are stuck after "Freeing unused Kernel image (initmem) memory" +See attached screen recording. +Rebooting the host with Kernel 5.17.13 solves the problem. +Steps to reproduce: +1. Boot host with Kernel >= 5.18.0 +2. Start VM +Additional information: +[bug.log](/uploads/faa14ac0bf84a21beb2ffeeb650df4b9/bug.log) +[qemu-libvirt-host-kernel-5.18.2.mkv](/uploads/87a064f171833e9fb3d46fd3ece32152/qemu-libvirt-host-kernel-5.18.2.mkv) diff --git a/results/classifier/deepseek-2/output/hypervisor/1069 b/results/classifier/deepseek-2/output/hypervisor/1069 new file mode 100644 index 000000000..0f4515b3b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1069 @@ -0,0 +1,14 @@ + +Qemu triggers the split lock detection of the Linux kernel +Description of problem: +Windows displays a "blue screen of death" and the Linux kernel logs this error message: + +``` +[ 180.886150] x86/split lock detection: #AC: qemu-system-x86/10167 took a split_lock trap at address: 0x3ff2624d +[ 180.946151] x86/split lock detection: #AC: qemu-system-x86/10168 took a split_lock trap at address: 0x3ff2624d +``` +Steps to reproduce: +1. Start the guest OS +2. Do some stuff in the Windows guest (for instance OS updates) +Additional information: +Is this a bug in Windows or in Qemu ? diff --git a/results/classifier/deepseek-2/output/hypervisor/1072 b/results/classifier/deepseek-2/output/hypervisor/1072 new file mode 100644 index 000000000..0181b249b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1072 @@ -0,0 +1,25 @@ + +different behavior when remote debugger is used +Description of problem: +I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: + +1. Is this intended behavior? +1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below) +1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference. + +The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR) +The preprocessed code is as follows: + if (((((st.st_mode)) & 0170000) == (0020000))) + +I then compared two different approaches to run Qemu: + +1. I used the following command line to collect the trace: qemu_aarch64 -strace -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR +1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). + +Thanks! +Steps to reproduce: +1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64) +2. +3. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1073 b/results/classifier/deepseek-2/output/hypervisor/1073 new file mode 100644 index 000000000..c5dae0a9c --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1078892 b/results/classifier/deepseek-2/output/hypervisor/1078892 new file mode 100644 index 000000000..31d1a57f8 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1083 b/results/classifier/deepseek-2/output/hypervisor/1083 new file mode 100644 index 000000000..87da5aee7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1083 @@ -0,0 +1,2 @@ + +Qemu on Windows - Emulate 64Bit CPU diff --git a/results/classifier/deepseek-2/output/hypervisor/1084 b/results/classifier/deepseek-2/output/hypervisor/1084 new file mode 100644 index 000000000..4024bfbc8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1084 @@ -0,0 +1,2 @@ + +Qemu - VCPU shutdown request error diff --git a/results/classifier/deepseek-2/output/hypervisor/1089281 b/results/classifier/deepseek-2/output/hypervisor/1089281 new file mode 100644 index 000000000..7752ece29 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1089281 @@ -0,0 +1,55 @@ + +kvm crash when writing on disk + +When running the following command: + +/usr/bin/kvm -S -M pc-1.0 -cpu qemu32 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name winxp -uuid f86ef88f-b90e-699a-74b8-9675063fc26e -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device lsi,id=scsi0,bus=pci.0,addr=0x4 -drive file=/home/master/xpnew.iso,if=none,media=cdrom,id=drive-ide0-0-0,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/var/lib/zentyal/machines/winxp/winxp.img,if=none,id=drive-scsi0-0-0,format=qcow2 -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=18,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=b3:b8:a9:49:a2:f8,bus=pci.0,addr=0x3 -usb -device usb-mouse,id=input0 -vnc 0.0.0.0:0,password -k de -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + + +running a windows installation (for instance, it has crashed with other OS), when the guest OS installer has reached 60% of the copying files process, the following errors can be found, and KVM gets Force Closed (i am recollecting errors from different times I have tried to references to memory positions may vary) + +syslog: + +Nov 26 19:46:59 mikeboxx kernel: [2254718.689953] kvm6983 general protection ip:7fc451d4be08 sp:7fc44991ab80 error:0 in libc-2.15.so[7fc451ccd000+1b5000] + +/var/log/libvirt/libvirtd.log: + +2012-11-21 10:01:26.464+0000: 16050: error : qemuMonitorIO:603 : internal error End of file from monitor + +/var/log/libvirt/qemu/winxp-ajur.log + +**enclosed as it has a long size due to the core dump + + +The linux kernel running is this one: + +3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +Libvirtd versions are these: +root@mikeboxx:/home/ebox-remote-support# dpkg -l | grep libvirt +ii libvirt-bin 0.9.8-2ubuntu17.4 programs for the libvirt library +ii libvirt0 0.9.8-2ubuntu17.4 library for interfacing with different virtualization systems + +and KVM - QEMU versions are these ones: +root@mikeboxx:/home/ebox-remote-support# dpkg -l | grep qemu +ii qemu-common 1.0+noroms-0ubuntu14.3 qemu common functionality (bios, documentation, etc) +ii qemu-kvm 1.0+noroms-0ubuntu14.3 Full virtualization on i386 and amd64 hardware +ii qemu-utils 1.0+noroms-0ubuntu14.3 qemu utilities + + + +I have checked bug #1022901 in https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1022901 due to the similarity of the error "internal error End of file from monitor", but the sintoms are not the same as long as the partition where the img file resides has plenty of space and so does the img itself: + +root@mikeboxx:/home/ebox-remote-support# df -h +Filesystem Size Used Avail Use% Mounted on +/dev/sda1 226G 3.4G 211G 2% / + +root@mikeboxx:/home/ebox-remote-support# qemu-img info /var/lib/zentyal/machines/winxp/winxp.img +image: /var/lib/zentyal/machines/winxp/winxp.img +file format: qcow2 +virtual size: 11G (11559501824 bytes) +disk size: 384M +cluster_size: 65536 + + +Can you help us to solve this? Case you needed any information else, please do not hesitate to ask for it \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1091 b/results/classifier/deepseek-2/output/hypervisor/1091 new file mode 100644 index 000000000..2b1e71841 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1091 @@ -0,0 +1,14 @@ + +qemu-system-x86_64 hard crashes when using `--accel hvf` on intel Mac +Description of problem: +The QEMU process hard crashes after a few minutes. The only message is: + +``` +vmx_write_mem: mmu_gva_to_gpa ffff990489fa0000 failed +``` +Steps to reproduce: +1. Run QEMU with the above commandline +2. Do something to keep the VM busy - running `git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git` reliably crashes it for me +3. Wait a 3-5 minutes +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1091115 b/results/classifier/deepseek-2/output/hypervisor/1091115 new file mode 100644 index 000000000..3742fdceb --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1091115 @@ -0,0 +1,16 @@ + +windowsXP install in qemu-system-i386 1.3.0 ends with a BSOD 0x7E in acpi.sys + +These are the commands: +$git checkout v1.3.0 +$./configure --prefix=/home/user/tmp --target-list=i386-softmmu --enable-sdl --disable-curses --disable-vnc --enable-kvm --disable-docs +$make +$make install +In /home/user/tmp directory: +$./bin/qemu-img create imgs/winxp.img 4G +$./bin/qemu-system-i386 imgs/winxp.img -cdrom ~/Downloads/zh-hans_windows_xp_professional_with_service_pack_3_x86_cd_x14-80404.iso + +then it show a bluescreen after a few seconds. +See the attachment for more information, please. + +It works well when checking out v1.2.0. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1102027 b/results/classifier/deepseek-2/output/hypervisor/1102027 new file mode 100644 index 000000000..f320dddac --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1102027 @@ -0,0 +1,10 @@ + +QED Time travel + +This night after a reboot of a VM, it was back to 8 Oct. 2012, i've lost all data between 8 Oct 2012 and now. I've check the QED file and mount on another VM, all seems OK. + +This QED has a raw backfile with the base OS (debian) shared with many others QED. It has NO snapshot. + +QEMU emulator version 1.1.2 + +Does anyone have a hint ? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1111 b/results/classifier/deepseek-2/output/hypervisor/1111 new file mode 100644 index 000000000..b7cbf51de --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1111 @@ -0,0 +1,19 @@ + +Calling FUTEX_LOCK_PI with qemu-x86_64-static caused ENOSYS error. +Description of problem: +When I executed the command "perf bench futex lock-pi" in amd64 docker image on s390x, I got the following error. +``` +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +``` + +I searched for this error message in the source code of perf-bench. I think that the following system call caused ENOSYS error. +` syscall(SYS_futex, uaddr, FUTEX_LOCK_PI | opflags, val, timeout, uaddr2, val3)` +Steps to reproduce: +1. Execute the command "perf bench futex lock-pi" in amd64 docker image on s390x +2. +3. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1120383 b/results/classifier/deepseek-2/output/hypervisor/1120383 new file mode 100644 index 000000000..81a156d77 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1120383 @@ -0,0 +1,28 @@ + +incremental live block migration of qemu 1.3.1 doesn't work + +We tested qemu 1.3.1 for live migration of block device. It failed with error. Since qemu-kvm 1.2.0 is ok for this test, we think this problem is introduced by new qemu 1.3.x releases. + +To reproduce: + +1. compile qemu 1.3.1: + # cd qemu-1.3.1 + # ./configure --prefix=/usr --sysconfdir=/etc --target-list=x86_64-softmmu + # make; make install + +2. prepare source(172.16.1.13): + # qemu-img create -f qcow2 os.img -b /home/reno/wheezyx64 ###Note: wheezyx64 is a template image for Debian Wheezy + # qemu-system-x86_64 -hda os.img -m 512 --enable-kvm -vnc :51 -monitor stdio + +3. prepare destination(172.16.1.14): + # qemu-img create -f qcow2 os.img -b /home/reno/wheezyx64 + # qemu-system-x86_64 -hda os.img -m 512 --enable-kvm -vnc :51 -incoming tcp:0:4444 + +4. do live migrate: + on source monitor command prompt, input: + (qemu) migrate -i tcp:172.16.1.14:4444 + +monitor command will quit immediately and on destination host, there are errors thrown: + Receiving block device images + Co-routine re-entered recursively + Aborted \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1124 b/results/classifier/deepseek-2/output/hypervisor/1124 new file mode 100644 index 000000000..a1c32ded8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1124 @@ -0,0 +1,2 @@ + +AIX 5 not working with qemu-system-ppc64 diff --git a/results/classifier/deepseek-2/output/hypervisor/1128935 b/results/classifier/deepseek-2/output/hypervisor/1128935 new file mode 100644 index 000000000..1719565f8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1128935 @@ -0,0 +1,24 @@ + +MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction + +I occasionally see that the TLBP instruction fails to find the corresponding TLB entry in the TLB Modified exception handler. This behavior is unexpected, because the invocation of the TLB Modified exception suggests there indeed is such an entry in the TLB and only requires its dirty bit to be set. + +The operating system which can trigger and is susceptible to this behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta. The QEMU version on which this is reproducible is QEMU 1.4.0 and also some others. + +When I looked into the QEMU sources, I noticed the following discrepancy, which could potentially explain the behavior: + + 65 /* MIPS32/MIPS64 R4000-style MMU emulation */ + 66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot, + 67 target_ulong address, int rw, int access_type) + 68 { + <snip> + 72 for (i = 0; i < env->tlb->tlb_in_use; i++) { + +1865 void r4k_helper_tlbp(CPUMIPSState *env) +1866 { + <snip> +1875 for (i = 0; i < env->tlb->nb_tlb; i++) { + +From the above it appears as if the the code which searches the TLB for a matching entry searched also the QEMU-specific "shadow" TLB entries, which is, however, not in line with how the TLBP instruction searches the TLB. So if a matching entry is found on index >= tlb_in_use, the HelenOS exception handler using TLBP to locate the entry would hit an assertion on seeing the Index register bit P set. + +I also suspect there is a similar issue with the TLB Invalid exception, but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is not susceptible in this case. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1133 b/results/classifier/deepseek-2/output/hypervisor/1133 new file mode 100644 index 000000000..b1738e93e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1133 @@ -0,0 +1,11 @@ + +unused memory filled with 0x00 instead of 0xFF +Description of problem: +Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem? + +Refer to +https://bugs.launchpad.net/qemu/+bug/1180923 +Steps to reproduce: +1. +2. +3. diff --git a/results/classifier/deepseek-2/output/hypervisor/1140 b/results/classifier/deepseek-2/output/hypervisor/1140 new file mode 100644 index 000000000..a37dda96b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1140 @@ -0,0 +1,2 @@ + +High CPU usage on AMD after migrating guests diff --git a/results/classifier/deepseek-2/output/hypervisor/1142 b/results/classifier/deepseek-2/output/hypervisor/1142 new file mode 100644 index 000000000..116875789 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1142 @@ -0,0 +1,47 @@ + +Measurements fail with direct kernel boot for AMD SEV confidential virtualization with 7.1 machine type +Description of problem: +When booting the QEMU with the 'kernel-hashes:true' property set for 'sev-guest' confidential virtualization, the contents of the `-kernel` file are measured by the firmware. + +A remote tenant can then validate the measurement against its expected contents to see if the boot was trustworthy. + +With the pc-q35-7.1 machine type the measurement always fails to validate against expected state. + +Making the following code change + +``` +diff --git a/hw/i386/pc.c b/hw/i386/pc.c +index 7280c02ce3..3a4bf5cba3 100644 +--- a/hw/i386/pc.c ++++ b/hw/i386/pc.c +@@ -1899,6 +1899,8 @@ static void pc_machine_class_init(ObjectClass *oc, void *data) + pcmc->rsdp_in_ram = true; + pcmc->smbios_defaults = true; + pcmc->smbios_uuid_encoded = true; ++ pcmc->legacy_no_rng_seed = true; ++ + pcmc->gigabyte_align = true; + pcmc->has_reserved_memory = true; + pcmc->kvmclock_enabled = true; +``` + +results in successfully validating the measurement. + +THis is not surprising, the RNG seed patch introduced in + +``` +commit 67f7e426e53833a5db75b0d813e8d537b8a75bd2 +Author: Jason A. Donenfeld <Jason@zx2c4.com> +Date: Thu Jul 21 14:56:36 2022 +0200 + + hw/i386: pass RNG seed via setup_data entry +``` + +intentionally modifies the contents of the kernel image before passing it to the firmware, to inject a random seed. This will ensure the boot measuremnts are different every time. + +This RNG seed functionality must NOT be used when AMD SEV is active. +Steps to reproduce: +1. Create an AMD SEV guest with kernel-hashes=true and pc-q35-7.1 machine type +2. Attempt to validate the boot measurement +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1151 b/results/classifier/deepseek-2/output/hypervisor/1151 new file mode 100644 index 000000000..097f74db5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1151 @@ -0,0 +1,50 @@ + +when guest unexpect shutdown,can't enter system,the terminal has a black screen +Description of problem: + +Steps to reproduce: +1.guest unexpect shutdown + +2.when start again,cpu usage is high and can't enter the guest system + +3.restart guest can recovery + +**libvirt print：** + +`2022-08-11 14:39:58.080+0000: 1942: warning : qemuDomainObjTaint:6079 : Domain id=117 name='GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d' uuid=99d2578e-f06e-4fbe-88dd-7d9dd56fd02d is tainted: high-privileges + +2022-08-11 14:39:58.080+0000: 1942: warning : qemuDomainObjTaint:6079 : Domain id=117 name='GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d' uuid=99d2578e-f06e-4fbe-88dd-7d9dd56fd02d is tainted: custom-argv + +2022-08-11 14:40:28.792+0000: 741037: warning : qemuDomainObjBeginJobInternal:946 : Cannot start job (modify, none, none) for domain GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d; current job is (none, none, migration in) owned by (0 <null>, 0 <null>, 0 remoteDispatchDomainMigratePrepare3Params (flags=0x203)) for (0s, 0s, 30s) + +2022-08-11 14:40:28.792+0000: 741037: error : qemuDomainObjBeginJobInternal:968 : Timed out during operation: cannot acquire state change lock (held by monitor=remoteDispatchDomainMigratePrepare3Params) +` + + +**user perf to analyse:** + +\#top -d 3 -Hp 1311519 + + + +\#perf record -a -g -p 1311519 sleep 20 + +\#report -n --header --stdio + + + + +**query kvm stat:** + + \# perf stat -e 'kvm:*' -a -p 1311519 sleep 20 + + + + +kvm vmexit stat: + +\#perf kvm stat record -a -p 1311519 sleep 10 + +\#perf kvm stat report --event=vmexit + + diff --git a/results/classifier/deepseek-2/output/hypervisor/1152 b/results/classifier/deepseek-2/output/hypervisor/1152 new file mode 100644 index 000000000..e449acecd --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1155 b/results/classifier/deepseek-2/output/hypervisor/1155 new file mode 100644 index 000000000..13a784d54 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1155 @@ -0,0 +1,28 @@ + +RISC-V: Instruction fetch exceptions can have invalid tval/epc combination +Description of problem: +Instruction page fault / guest-page fault / access fault exceptions can have invalid `epc`/`tval` combinations, for example as shown in the debug log: + +``` +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000014, epc:0xffffffff802fec76, tval:0xffffffff802ff000, desc=guest_exec_page_fault +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000014, epc:0xffffffff80243fe6, tval:0xffffffff80244000, desc=guest_exec_page_fault +``` + +From the privileged spec: + +> If `mtval` is written with a nonzero value when an instruction access-fault or page-fault exception occurs on a system with variable-length instructions, then `mtval` will contain the virtual address of the portion of the instruction that caused the fault, while `mepc` will point to the beginning of the instruction. + +Currently RISC-V only has 32-bit and 16-bit instructions, so the difference `tval - epc` should be either `0` or `2`. In the examples above the differences are `906` and `26` respectively. + +Possibly notable: all occurrences of these invalid combinations to have `tval` aligned to a page-boundary. +Steps to reproduce: +This one only gives invalid `tval`/`epc` combinations with instruction guest-page faults, but I've found it to be the easiest reproducer to describe, since presumably running KVM in RISC-V QEMU is a standard setup. I have not otherwise been able to find a more minimal case. + +1. Start a QEMU-based `riscv64` machine +2. Start a KVM-based virtual machine with QEMU inside it +3. Do some stuff in the KVM-based virtual machine to increase the chance of page faults +4. Look in the debug log of the outer QEMU for `guest_exec_page_fault` exceptions with `tval` ending in `000`, but `epc` ending in neither `000` nor `ffe` + +Everything in both layers of guests should otherwise work without issue, but other/future software that relies on the spec-mandated relationship of `epc`/`tval` may break. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1156 b/results/classifier/deepseek-2/output/hypervisor/1156 new file mode 100644 index 000000000..4da98ecd2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1156 @@ -0,0 +1,2 @@ + +Incorrect implementation of vmsumudm instruction diff --git a/results/classifier/deepseek-2/output/hypervisor/1163474 b/results/classifier/deepseek-2/output/hypervisor/1163474 new file mode 100644 index 000000000..20c404032 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1163474 @@ -0,0 +1,12 @@ + +qemu mount usb permission denied + +I use debian with kde and the new Qemu 14.0 . I use this Qemu start arguments: + +/usr/bin/qemu-system-x86_64 -monitor stdio -smp 2 -soundhw es1370,ac97 -k de -enable-kvm -m 4096 -localtime -cdrom /dev/sr0 -hda /home/....../.aqemu/Windows_7_x64_HDA.img -boot once=d,menu=off -net nic,vlan=0 -net user,vlan=0 -usb -usbdevice tablet -device usb-host,hostbus=1,hostaddr=2 -device usb-host,hostbus=2,hostaddr=2 -name "Windows 7 x64" + +Then I get this error: /dev/bus/usb/000/001: Permission denied + +Some says I must change the permissions /dev/bus/usb to 777 but I think that can't be the solution and when I restart the changes are lost. I think there is also a problem with the automount in KDE. + +The user user who starts Qemu has also full access to usb device (member of the group plugdev) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1165 b/results/classifier/deepseek-2/output/hypervisor/1165 new file mode 100644 index 000000000..3e3e989fb --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1165 @@ -0,0 +1,4 @@ + +About support LoongArch architecture +Additional information: +Start from Linux 5.19, maybe can find the compatible source code for LoongArch in the Linux Kernel source code archive. diff --git a/results/classifier/deepseek-2/output/hypervisor/1166 b/results/classifier/deepseek-2/output/hypervisor/1166 new file mode 100644 index 000000000..2a65efac3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1166 @@ -0,0 +1,26 @@ + +Solaris 2.6 panic when debugging with gdb +Description of problem: +Running gdb with a breakpoint that gets hit triggers a panic: +``` +non parity synchronous error ctx=fa va=ef7d97c pa=c1a47c +``` + +One time I got of the following messages as well +``` +processor level 12 onboard interrupt not serviced +processor level 12 onboard interrupt not serviced +... +``` +Steps to reproduce: +1. Install Solaris 2.6 using https://learn.adafruit.com/build-your-own-sparc-with-qemu-and-solaris?view=all +2. Install https://archive.org/details/sun26gnu +3. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gdb-6.8-sol26-sparc-local.gz +4. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gcc-2.95.3-sol26-sparc-local.gz +5. Build a simple hello world program with debugging information +6. +``` +gdb ./hello +(gdb) break main +(gdb) run +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/1167 b/results/classifier/deepseek-2/output/hypervisor/1167 new file mode 100644 index 000000000..1fdc389d9 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1175089 b/results/classifier/deepseek-2/output/hypervisor/1175089 new file mode 100644 index 000000000..47e21d490 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1175089 @@ -0,0 +1,25 @@ + +Crash why dragon fly 3.4.1 + +Hello, all is here (kernel 3.8, qemu 1.2.2-r3): +/usr/bin/qemu-system-x86_64 -k fr -alt-grab -m 2048 -vga vmware -net nic,vlan=0,model=virtio -net user -rtc base=localtime -smp 4,cores=4,sockets=1 -boot once=d -cdrom dfly-x86_64-gui-3.4.1_REL.iso +KVM internal error. Suberror: 1 +emulation failure +EAX=00000010 EBX=00009338 ECX=00000000 EDX=00000000 +ESI=000017fc EDI=000017c8 EBP=000364a0 ESP=000017b8 +EIP=00009318 EFL=00003002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00c09300 +CS =0018 00000000 0000ffff 00009b00 +SS =0010 00000000 ffffffff 00c09300 +DS =0010 00000000 ffffffff 00c09300 +FS =0033 0000a000 ffffffff 00c0f300 +GS =0033 0000a000 ffffffff 00c0f300 +LDT=0000 00000000 0000ffff 00008200 +TR =0038 00005f98 00002067 00008b00 +GDT= 00009590 0000003f +IDT= 00005e00 00000197 +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 a3 ea 5d 00 00 66 ea 10 93 18 00 0f 20 c0 fe c8 0f 22 c0 <ea> 1d 93 00 00 31 c0 8e d8 8e d0 0f 01 1e dc 95 66 07 66 1f 66 0f a1 66 0f a9 66 61 bc ea \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1180923 b/results/classifier/deepseek-2/output/hypervisor/1180923 new file mode 100644 index 000000000..79988ef61 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1180923 @@ -0,0 +1,4 @@ + +unused memory filled with 0x00 instead of 0xFF + +Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1182490 b/results/classifier/deepseek-2/output/hypervisor/1182490 new file mode 100644 index 000000000..cab3da2b6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1187 b/results/classifier/deepseek-2/output/hypervisor/1187 new file mode 100644 index 000000000..13f7db86d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1187 @@ -0,0 +1,2 @@ + +can not handler real-time signal (signal number > 30) by sigqueue on linux user mode diff --git a/results/classifier/deepseek-2/output/hypervisor/1188 b/results/classifier/deepseek-2/output/hypervisor/1188 new file mode 100644 index 000000000..feff171b4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1188 @@ -0,0 +1,5 @@ + +qapi: add support to default value for optional members +Additional information: +This is a proposal to the QAPI spec itself to have a simple way to express that +an absent member defaults to a value. diff --git a/results/classifier/deepseek-2/output/hypervisor/1190525 b/results/classifier/deepseek-2/output/hypervisor/1190525 new file mode 100644 index 000000000..c557976a6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1190525 @@ -0,0 +1,37 @@ + +fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk + +RHEL guest shows the partittions even after the removal of scsi disk: +fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk. + +Guest details: +------------------- +Kernel : 2.6.32-358 + + +Host Details : + +Upstream Kernel, Qemu, Libvirt and virt-manager +--------------------------------------------------------------------- + +kernel version : 3.9.0+ +qemu version : QEMU emulator version 1.5.0 +libvirt version : 1.0.5 +virt-install : 0.600.3 + + +Steps to reproduce the issue: + +I. Add the SCSI disk through the virt-manager. +2. Create the partition using fdisk (eg: /dev/sbb) +3. Create a filesystem and format using mkfs.ext3 or mkfs.ext4 +4. Remove the scsi disk through the virt-manager. +5. Again run the fdisk /dev/sdb, the guests still shows the partition even after the removal of the disk. + +This issue is not seen with virt-io disk. + +This issue is also reproducible without even creating the partitions. + +Expected Result: + +The output of fdisk /dev/sd* should not show the enties after the removal of scsi disks \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1192065 b/results/classifier/deepseek-2/output/hypervisor/1192065 new file mode 100644 index 000000000..95be77b54 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1192065 @@ -0,0 +1,7 @@ + +qemu release memory to system + +Qemu pre-allocates the maximum balloon amount which is inconvinient if all of the memory is used up and some other system needs to be added memory resource + +eg:- I have 4GB RAM with 4 virtual systems to be run. +I want each of them to start with 1GB RAM with maximum 2GB possible. This is not achievable since qemu pre-allocates the maximum balloon amount which is 2GBx4 systems . So to start all 4 systems the system needs 8GB RAM rather than 4GB RAM to start with although I have told initial balloon amount to be 1GB. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1192344 b/results/classifier/deepseek-2/output/hypervisor/1192344 new file mode 100644 index 000000000..4ebe936d7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1192344 @@ -0,0 +1,10 @@ + +qemu crashes on unaligned extended disk reads + +When performing a BIOS extended disk read (INT 13H, AH=0x42), if the offset of the buffer destination in the DAP (disk address packet) is not dword-aligned (i.e. a multiple of 4), SeaBIOS attempts to execute code at non-mapped address 0xb4f53, causing QEMU to crash. I imagine it's a bug in the BIOS code, but it does cause QEMU to crash. + +QEMU version: 1.4.0 (Debian 1.4.0+dfsg-1expubuntu4) (from Ubuntu repository) +SeaBIOS version: 1.7.2-20130119_170942-roseapple +command line: qemu-system-x86_64 -m 64 -hda hda.img -monitor stdio +CPU: Intel Core i7 CPU M620 on a Dell Latitude E6410 +OS: Ubuntu, GNU/Linux 3.8.0-25-generic, 64-bit \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1192499 b/results/classifier/deepseek-2/output/hypervisor/1192499 new file mode 100644 index 000000000..0a331288b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1192499 @@ -0,0 +1,103 @@ + +virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" + +virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" and shut downs the guest on the source host. + +Kernel Version: 3.10.0-rc5+ + +Libvirt Version: 1.0.6 + +Qemu Version: 1.5.50 + +Steps to reproduce the issue: +---------------------------------------- +1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host which is same as the source. +2. Started the guest on the source +3. Started the vncdisplay to monitor the guest +4. Initiated the migration "virsh migrate --live VM1 qemu+ssh://host-ip/system tcp://host-ip --verbose --copy-storage-all" +5. It started the copying the storage from souce to destination (conitinously monitored it was growing) +6. Guest on the destination was paused and was running on the source +7. At some point the VM on the source got shutdown and migration failed with "Unable to read from monitor: Connection reset by peer" + +Attached the libvirt debug logs. + +The debug logs shows : + +2013-06-19 08:43:12.253+0000: 4026: debug : virEventPollInterruptLocked:716 : Interrupting +2013-06-19 08:43:12.253+0000: 4026: debug : virEventPollAddTimeout:248 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) ff=(nil) + +Note: The virsh live migration works fine with nfs storage from source to destination and vice versa. +With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with that even "Live migration with nfs also was not working". + +Guest XML: +---------------- + +<domain type='kvm'> + <name>VM1</name> + <uuid>47feb0e1-0c23-9be9-da12-2ead34864de2</uuid> + <memory unit='KiB'>4096000</memory> + <currentMemory unit='KiB'>2048000</currentMemory> + <vcpu placement='auto'>1</vcpu> + <numatune> + <memory mode='strict' nodeset='0'/> + </numatune> + <os> + <type arch='x86_64' machine='pc-i440fx-1.5'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/local/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none'/> + <source file='/home/images/VM1.qcow2'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='block' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <interface type='network'> + <mac address='52:54:00:9d:cf:bb'/> + <source network='default'/> + <model type='rtl8139'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <video> + <model type='cirrus' vram='9216' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </memballoon> + </devices> + <seclabel type='none' model='selinux'/> +</domain> \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1195012 b/results/classifier/deepseek-2/output/hypervisor/1195012 new file mode 100644 index 000000000..eb37186cc --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1195012 @@ -0,0 +1,23 @@ + +x86_64 and i386 return 0 when reading MSR_TSC + +Running NetBSD 6.1 (i386 and amd64) under QEMU (from git - 1.5.50 is the version it shows) results in an incorrectly set +TSC frequency (set to 0), because NetBSD uses rdmsr(TSC_MSR) for its serializing CPU counter. + +To reproduce the problem, you can run an install ISO of NetBSD 6.1 (either i386 or amd64, depending on which qemu). Quit out of the installer, and you're left at a root prompt: + +# sysctl machdep.tsc_freq +machdep.tsc_freq = 0 + +...on real hardware, it will return the TSC frequency: + +# sysctl machdep.tsc_freq +machdep.tsc_freq = 3292685070 + +...this causes problems with a number of applications. + +The NetBSD code which reads the MSR is here: + +http://nxr.netbsd.org/xref/src/sys/arch/x86/x86/tsc.c#262 + +... the "rdmsr(MSR_TSC)" call in cpu_counter_serializing() always returns 0 when run under QEMU. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1196 b/results/classifier/deepseek-2/output/hypervisor/1196 new file mode 100644 index 000000000..2e6ca5270 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1196 @@ -0,0 +1,13 @@ + +Guest could not enable pci AtomicOp requests for passthrough device +Description of problem: +Guest could not enable pci AtomicOp requests for passthrough device. + +sudo setpci -v -d *:706t 8c.b=40 // enable pci AtomicOp requests bit in the guest os. + +Host could not see the bit by command "sudo lspci -vvv -s 03:00.0". +Steps to reproduce: +1. sudo setpci -v -d *:706t 8c.b=40 // in the guest os +2. sudo lspci -vvv -s 03:00.0 // in the host os +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1199 b/results/classifier/deepseek-2/output/hypervisor/1199 new file mode 100644 index 000000000..7d0f72046 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1201447 b/results/classifier/deepseek-2/output/hypervisor/1201447 new file mode 100644 index 000000000..88d7acadf --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1201447 @@ -0,0 +1,18 @@ + +Blue screen when disk uses cache='writeback' + +I am running Windows 2008R2 as KVM guest on Ubuntu 12.04 hypervisor. Disk controller and network card are virtio devices with drivers from https://launchpad.net/kvm-guest-drivers-windows/+download (virtio-win-drivers-20120712-1.iso). +Everything worked fine until I changed disk controller cache from the default (writethrough) to writeback. This introduced occasional blue screens. I noticed that they are linked to high disk IO. For example restoring over 1GB of backup files will results in a blue screen on around 4 out of 5 attempts. Also Windows update crashes the system sometimes. When idle the system will run fine for hours or sometimes even days. +After removing cache='writeback' from the config everything came back to normal. + +qemu-kvm: + Installed: 1.0+noroms-0ubuntu14.8 + Candidate: 1.0+noroms-0ubuntu14.8 + Version table: + *** 1.0+noroms-0ubuntu14.8 0 + 500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages + 100 /var/lib/dpkg/status + 1.0+noroms-0ubuntu14.7 0 + 500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages + 1.0+noroms-0ubuntu13 0 + 500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1207 b/results/classifier/deepseek-2/output/hypervisor/1207 new file mode 100644 index 000000000..86c1c238c --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1214 b/results/classifier/deepseek-2/output/hypervisor/1214 new file mode 100644 index 000000000..adb394d41 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1214 @@ -0,0 +1,2 @@ + +qemu-riscv64 mmap will exhaust all physical memory diff --git a/results/classifier/deepseek-2/output/hypervisor/1214884 b/results/classifier/deepseek-2/output/hypervisor/1214884 new file mode 100644 index 000000000..ccabf5e27 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1217339 b/results/classifier/deepseek-2/output/hypervisor/1217339 new file mode 100644 index 000000000..3b971f9d7 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1221 b/results/classifier/deepseek-2/output/hypervisor/1221 new file mode 100644 index 000000000..4b5be134d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1221 @@ -0,0 +1,30 @@ + +qga return "frozen" when vm just been created from snapfile +Steps to reproduce: +1. virsh create lisa.xml +Domain lisa created from lisa.xml + +2. virsh domblklist lisa + vda /mnt/a/b/srv.qcow2 + +3. virsh snapshot-create-as lisa --disk-only --diskspec vda,file=/tmp/f1,snapfile=/tmp/sp1 --no-metadata --quiesce +Domain snapshot 20220919165217 created + +4. virsh shutdown lisa +Domain lisa is being shutdown + +5. modify lisa.xml: replace /mnt/a/b/srv/qcow2 with /tmp/sp1 + +6. virsh create lisa.xml +Domain lisa created from lisa.xml + +7. virsh domblklist lisa + vda /tmp/sp1 + +8. virsh qemu-agent-command lisa '{"execute":"guest-fsfreeze-status"}' +{"return":"frozen"} + +9. virsh snapshot-create-as lisa --disk-only --diskspec vda,file=/tmp/f2,snapfile=/tmp/sp2 --no-metadata --quiesce +error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': The command guest-fsfreeze-freeze has been disabled for this instance +Additional information: +Is "frozen" a normal value in step8? If not, what's the best way to avoid this? diff --git a/results/classifier/deepseek-2/output/hypervisor/1222 b/results/classifier/deepseek-2/output/hypervisor/1222 new file mode 100644 index 000000000..72cd513ee --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1222 @@ -0,0 +1,22 @@ + +/proc/self/exe not handled in execve +Description of problem: +I am submitting this issue to track an issue for which it seems there have been a couple of patchsets (unsuccessfully) submitted. I am not able to give a detailed analysis of the problem as I am not aware of exactly what the issue is - I am raising this issue to attempt to bring one of these changes upstream as it seems there is a genuine bug here (hence multiple attempts to fix) but no tracking bug or attention. It's also causing my project to require a custom fork of qemu just for this. + +My (laymans) understanding of the bug is that golang can escape the emulation environment when it execs something to do with `execve /proc/self/exe`. Here is an excerpt from my internal docs from someone who has left the project, sorry I cannot be of more use... + +> Unfortunately, to run podman/buildah/skopeo using qemu-user (which just runs a single binary +> emulated, as opposed to qemu-system which runs an entire system but is harder to automate in +> toolchains) we need these patches because of a peculiar thing many golang applications do. They +> re-execute themselves using the execve syscall using /proc/self/exe as the executable. In +> non-emulated contexts this is fine, but in emulated contexts /proc/self/exe is actually the +> top-level emulator process and _not_ podman/buildah/skopeo. This causes all container storage +> operations to mysteriously fail, because the wrong binary is being executed. This issue was quite +> difficult to root cause. +Additional information: +Old patchsets that seem to be trying to fix this: +- http://next.patchew.org/QEMU/20210531055019.10149-1-yamamoto@midokura.com/20210531055019.10149-2-yamamoto@midokura.com/ +- https://patchew.org/QEMU/20190916155545.29928-1-olivier.dion@polymtl.ca/ +- https://patchew.org/QEMU/20190807135458.32440-1-dion@linutronix.de/ + +It seems that this github issue: https://github.com/golang/go/issues/42080 references the same issue. diff --git a/results/classifier/deepseek-2/output/hypervisor/1223 b/results/classifier/deepseek-2/output/hypervisor/1223 new file mode 100644 index 000000000..ef611e74d --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1225 b/results/classifier/deepseek-2/output/hypervisor/1225 new file mode 100644 index 000000000..ee4e9cde7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1225 @@ -0,0 +1,2 @@ + +Can't update to Windows 11 22H2 diff --git a/results/classifier/deepseek-2/output/hypervisor/1227 b/results/classifier/deepseek-2/output/hypervisor/1227 new file mode 100644 index 000000000..8b68c9e93 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1227 @@ -0,0 +1,2 @@ + +Guest Agent not waiting for Linux services to stop during shutdown diff --git a/results/classifier/deepseek-2/output/hypervisor/1230 b/results/classifier/deepseek-2/output/hypervisor/1230 new file mode 100644 index 000000000..13b41faf2 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1235 b/results/classifier/deepseek-2/output/hypervisor/1235 new file mode 100644 index 000000000..384b9ef1d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1235 @@ -0,0 +1,181 @@ + +Using packer and plugin qemu in the json file to create a RHEL 8.4 guest kvm vm, but ssh timeout error coming, but it is running fine in RHEL 7.9 +Description of problem: +I have RHEL 8.5 as the KVM host. I want to create a guest vm of RHEL 8.4 through packer type qemu and have a json file where all the configurations are mentioned. + +{ + +“builders”: [ + +{ + +“type”: “qemu”, + +“iso_url”: “/var/lib/libvirt/images/test.iso”, + +“iso_checksum”: “md5:3959597d89e8c20d58c4514a7cf3bc7f”, + +“output_directory”: “/var/lib/libvirt/images/iso-dir/test”, + +“disk_size”: “55G”, + +“headless”: “true”, + +“qemuargs”: [ + + [ + + "-m", + + "4096" + + ], + + [ + + "-smp", + + "2" + + ] +], + +“format”: “qcow2”, + +“shutdown_command”: “echo ‘nonrootuser’ | sudo -S shutdown -P now”, + +“accelerator”: “kvm”, + +“ssh_username”: “nonrootuser”, + +“ssh_password”: “********”, + +“ssh_timeout”: “20m”, + +“vm_name”: “test”, + +“net_device”: “virtio-net”, + +“disk_interface”: “virtio”, + +“http_directory”: “/home/azureuser/http”, + +“boot_wait”: “10s”, + +“boot_command”: [ + +“e inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/anaconda-ks.cfg” + +] + +} + +], + +“provisioners”: + +[ + +{ + + "type": "file", + + "source": "/home/azureuser/service_status_check.sh", + + "destination": "/tmp/service_status_check.sh" + +}, + +{ + + "type": "file", + + "source": "/home/azureuser/service_check.sh", + + "destination": "/tmp/service_check.sh" + +}, + +{ + + "type": "file", + + "source": "/home/azureuser/azure.sh", + + "destination": "/tmp/azure.sh" + +}, + +{ + + + "type": "file", + + "source": "/home/azureuser/params.cfg", + + "destination": "/tmp/params.cfg" + +}, + + + +{ + + "type": "shell" , + + + + "execute_command": "echo 'siedgerexuser' | {{.Vars}} sudo -E -S bash '{{.Path}}'", + + + + "inline": [ +"echo copying" , "cp /tmp/params.cfg /root/", + "sudo ls -lrt /root/params.cfg", + "sudo ls -lrt /opt/scripts/" + ], + + + "inline_shebang": "/bin/sh -x" + +}, + +{ + + "type": "shell", + + "pause_before": "5s", + "expect_disconnect": true , + + "inline": [ + "echo runningconfigurescript" , "sudo sh /opt/scripts/configure-env.sh" + + ] + +}, + +{ + + "type": "shell", + + "pause_before": "200s", + + "inline": [ + + "sudo sh /tmp/service_check.sh", + "sudo sh /tmp/azure.sh" + + ] + +} +] + +} + +It is working fine in rhel 7.9, but the same thing giving ssh timeout error in RHEL 8.4. + +But when i am creating guest vm with virt-install it is able to create a vm and i am able to see it in cockpit web ui, but when i initiate packer build with qemu plugin then giving ssh timeout error it is not visible in cockpit UI, so not able to see where the guest vm created get stuck. + +Can anyone please help me to fix this issue where why vm not able to come up and also why qemu created vm not visible in cockpit web ui as that will be really helpful while debugging +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1242963 b/results/classifier/deepseek-2/output/hypervisor/1242963 new file mode 100644 index 000000000..38e95b432 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1242963 @@ -0,0 +1,27 @@ + +QEMU loadvm causes guest OS freeze + +HOST: ubuntu 13.10 x64 +GUEST: winxp sp 3 x86 + +AFFECT QEMU(tested): v1.5.2, v1.5.3, v1.6.0, v1.6.1 + +I compile QEMU by myself with "./configure --target-list=i386-softmmu && make && make install". +After installing a winxp sp3 into the qemu-system-i386 with command line: +> qemu-system-i386 -m 512 -hda xp.img -net user -net nic,model=rtl8139 -rtc base=localtime,clock=vm + +I use monitor to create a live snapshot: +> stop +> savevm xxx +> cont + +And then I load this snapshot (I also try it in commad line: -loadvm xxx): +> loadvm xxx +> cont + +After that, the windows system is freeze (don't accept any keyboard or mouse input, although I knew vcpu is still working). + +If I compile with -enable-kvm and launch qemu-system-i386 with -enable-kvm, it looks like everything works well. +I think it is a bug for qemu system. + +BTW: freeze is not appearing 100%, but in my test, 95% cases would cause system freeze. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1243968 b/results/classifier/deepseek-2/output/hypervisor/1243968 new file mode 100644 index 000000000..9fb52d0ac --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1245 b/results/classifier/deepseek-2/output/hypervisor/1245 new file mode 100644 index 000000000..c65a33fd3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1245 @@ -0,0 +1,2 @@ + +arm: cp15 support diff --git a/results/classifier/deepseek-2/output/hypervisor/1246890 b/results/classifier/deepseek-2/output/hypervisor/1246890 new file mode 100644 index 000000000..a8cff8c53 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1246890 @@ -0,0 +1,15 @@ + +AC97 sound card crashes QEMU + +The AC97 sound card does not work. It stops QEMU on startup. The cause appears to be some kind of deadlock. + +Steps to reproduce: +Just add -soundhw ac97 to QEMU's arguments. Example: qemu-system-ppc -soundhw ac97 + +The example above is all it takes to reproduce the problem. + +This problem has been observed on Mac OS X and Debian Linux. + +I question whether the ac97 support ever worked. It is a file that was taken from VirtualBox and added to QEMU. I do know that VirtualBox's support for the ac97 sound card works perfectly. + +The exact line of code that stops QEMU in its tracks is located in the file main-loop.c, in the function os_host_main_loop_wait(), the call made to qemu_mutex_lock_iothread(). The is where QEMU stops under Mac OS X. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1250360 b/results/classifier/deepseek-2/output/hypervisor/1250360 new file mode 100644 index 000000000..73f4f2900 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1250360 @@ -0,0 +1,35 @@ + +qcow2 image logical corruption after host crash + +Description of problem: +In case of power failure disk images that were active and created in qcow2 format can become logically corrupt so that they actually appear as unused (full of zeroes). +Data seems to be there, but at this moment i cannot find any reliable method to recover it. Should it be a raw image, a recovery path would be available, but a qcow2 image only presents zeroes once it gets corrupted. My understanding is that the blockmap of the image gets reset and the image is then assumed to be unused. +My detailed setup : + +Kernel 2.6.32-358.18.1.el6.x86_64 +qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64 +Used via libvirt libvirt-0.10.2-18.el6_4.14.x86_64 +The image was used from a NFS share (the nfs server did NOT crash and remained permanently active). + +qemu-img check finds no corruption; +qemu-img convert will fully convert the image to raw at a raw image full of zeroes. However, there is data in the file, and the storage backend was not restarted, inactivated during the incident. +I encountered this issue on two different machines, in both cases i was not able to recover the data. +Image was qcow2, thin provisioned, created like this : + qemu-img create -f qcow2 -o cluster_size=2M imagename.img + +While addressing the root cause in order to not have this issue repeat would be the ideal scenario, a temporary workaround to run on the affected qcow2 image to "patch" it and recover the data (eventually after a full fsck/recovery inside the guest) would also be good. Otherwise we are basically losing data on a large scale when using qcow2. + + + +Version-Release number of selected component (if applicable): +Kernel 2.6.32-358.18.1.el6.x86_64 +qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64 +Used via libvirt libvirt-0.10.2-18.el6_4.14.x86_64 + +How reproducible: +I am not able (and don't have at the moment enough resources to try to manually reproduce it), but the probability of the issue seems quite high as this is the second case of such corruption in weeks. +Additional info: +I can privately provide an image displaying the corruption. + +The reported problem has actually two aspects : first is the cause that eventually produces this issue. +The second is the fact that once the logical corruption has occured, qemu-img check finds nothing wrong with the image - this is obviously wrong. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1252010 b/results/classifier/deepseek-2/output/hypervisor/1252010 new file mode 100644 index 000000000..6c9ec3d27 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1252010 @@ -0,0 +1,8 @@ + +can't assign enough RAM to the VM + +QEMU version: 1.6.90.0 from 2013 11 16 +Host OS: Windows XP SP3 x86 +Host machine: 3.2 GHz AMD Athlon 64 dual core processor, 4 GB DDR II (3.2 seen by the OS) memory +Guest OS: Grub4Dos boot manager menu +Problem: you can't assign more than 880 MB memory to the VM, although with 0.15.1.0 version you can assign up to 1179 MB. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1253777 b/results/classifier/deepseek-2/output/hypervisor/1253777 new file mode 100644 index 000000000..ca61dbd44 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1253777 @@ -0,0 +1,20 @@ + +OpenBSD VM running on OpenBSD host has sleep calls taking twice as long as they should + +Running a script like + +while [ 1 ] +do + date + sleep 1 +done + +on the VM will result in the (correct) date being displayed, but it is displayed only every two (!) seconds. We have also noticed that if we connect to the VM's console using VNC, and move the mouse pointer constantly in the VNC window, the script runs normally with updates every second! Note that the script doesn't have to be running on the VM's console - it's also possible to (say) ssh to the VM from a separate machine and run the script and it will display the '2 second' issue, but as soon as you move the mouse pointer constantly in the VNC console window the script starts behaving normally with updates every second. + +I have only seen this bug when running an OpenBSD VM on an OpenBSD host. Running an OpenBSD VM on a Linux host does not exhibit the problem for me. I also belive (am told) that a Linux VM running on an OpenBSD host does not exhibit the problem. + +I have been using the OpenBSD 5.4 64 bit distro which comes with qemu 1.5.1 in a package, however I tried compiling qemu 1.6.1 and that has the same bug. In fact older OpenBSD distros have the same issue - going back to OpenBSD distros from two years ago still have the problem. This is not a 'new' bug recently introduced. + +Initially I wondered if it could be traced to an incorrectly set command line option, but I've since gone through many of the options in the man page simply trying different values (eg. different CPU types ( -cpu) , different emulated PC (-M)) but so far the problem remains. + +I'm quite happy to run tests in order to track this bug down better. We use qemu running on OpenBSD extensively and find it very useful! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1256548 b/results/classifier/deepseek-2/output/hypervisor/1256548 new file mode 100644 index 000000000..3352880e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1256548 @@ -0,0 +1,12 @@ + +qemu windows guest issues + +Ive noticed the following in the latest qemu build on mingw 64bit for windows + +older guests like windows 9* no longer boot they mostly just bsod its been this way for ages same with 32bit builds +xp 64bit and other 64bit windows guests no longer work and havent for ages same with 32bit builds +xp 32bit guest doesent work under 64bit builds but they work on 32bit builds + +are the issues with the coroutine stuff on windows builds being worked on? id gladly test patches + +just a few observations is all :) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1256826 b/results/classifier/deepseek-2/output/hypervisor/1256826 new file mode 100644 index 000000000..db85310fc --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1256826 @@ -0,0 +1,12 @@ + +INT instruction bug in WindowsXP + +This bug is in -no-kvm mode. + +In windowsXP at IDT entry 2&8 is Task gate + +when application use INT 2 or INT 8 it will cause blue screen in XP. + +I found it should cause #GP not generate hw interrupt. + +also I check this bug with -enable-kvm and works correctly. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1257 b/results/classifier/deepseek-2/output/hypervisor/1257 new file mode 100644 index 000000000..07147ee65 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1258 b/results/classifier/deepseek-2/output/hypervisor/1258 new file mode 100644 index 000000000..a0fd1212d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1258 @@ -0,0 +1,2 @@ + +nios2 system tests are exiting early and not showing an error diff --git a/results/classifier/deepseek-2/output/hypervisor/1259 b/results/classifier/deepseek-2/output/hypervisor/1259 new file mode 100644 index 000000000..690f1164b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1259 @@ -0,0 +1,2 @@ + +RISC-V csr diff --git a/results/classifier/deepseek-2/output/hypervisor/1259499 b/results/classifier/deepseek-2/output/hypervisor/1259499 new file mode 100644 index 000000000..1777e33cd --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1259499 @@ -0,0 +1,36 @@ + +QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system-x86_64 + +I have upgraded to QEmu 1.7.0 (Debian 1.7.0+dfsg-2) but now when I try to restore a live snapshot made in QEmu 1.6.0 (Debian 1.6.0+dfsg-1) I see that the VM boots from scratch instead of starting directly in the snapshot's running state. + +Furthermore if the VM is already running and I try to revert to the snapshot again I get the following message: + +$ virsh --connect qemu:///system snapshot-revert fgtbbuild wtb; echo $? +error: operation failed: Error -22 while loading VM state +1 + +I have test VMs with live snapshots corresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu bug it looks like I'll have to do it again. + +This all sounds very much like bug 1123975 where QEmu 1.3 broke compatibility with previous versions live snapshots :-( + +Here is the command being run by libvirt: + +/usr/bin/qemu-system-x86_64 -name fgtbbuild -S -machine pc-1.1,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid f510955c-17de-9907-1e33-dfe1ef7a08b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbbuild.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbbuild.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0a:3c:e8,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -loadvm wtb + +ipxe-qemu 1.0.0+git-20120202.f6840ba-3 +qemu 1.7.0+dfsg-2 +qemu-keymaps 1.7.0+dfsg-2 +qemu-slof 20130430+dfsg-1 +qemu-system 1.7.0+dfsg-2 +qemu-system-arm 1.7.0+dfsg-2 +qemu-system-common 1.7.0+dfsg-2 +qemu-system-mips 1.7.0+dfsg-2 +qemu-system-misc 1.7.0+dfsg-2 +qemu-system-ppc 1.7.0+dfsg-2 +qemu-system-sparc 1.7.0+dfsg-2 +qemu-system-x86 1.7.0+dfsg-2 +qemu-user 1.7.0+dfsg-2 +qemu-utils 1.7.0+dfsg-2 +libvirt-bin 1.1.4-2 +libvirt0 1.1.4-2 +libvirtodbc0 6.1.6+dfsg-4 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1266 b/results/classifier/deepseek-2/output/hypervisor/1266 new file mode 100644 index 000000000..747d82ff0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1266 @@ -0,0 +1,2 @@ + +Assert in resettable_phase_enter through virtio-scsi diff --git a/results/classifier/deepseek-2/output/hypervisor/1268 b/results/classifier/deepseek-2/output/hypervisor/1268 new file mode 100644 index 000000000..0a624c810 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1268 @@ -0,0 +1,2 @@ + +erst: undefined-behavior in memcpy in write_erst_record diff --git a/results/classifier/deepseek-2/output/hypervisor/1270 b/results/classifier/deepseek-2/output/hypervisor/1270 new file mode 100644 index 000000000..b995a2881 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1274 b/results/classifier/deepseek-2/output/hypervisor/1274 new file mode 100644 index 000000000..0b7785ca7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1274 @@ -0,0 +1,33 @@ + +Cannot debug init using "qemu -s -S" if init is compiled dynamically or if kvm is enabled +Description of problem: +I'm trying to connect from host to init process running in guest. I'm using this guide: https://qemu-project.gitlab.io/qemu/system/gdb.html . Everything works well, but there is two problems: +1. Debugging stops to work if I add "-enable-kvm" +2. Debugging stops to work if I remove "-static" when compiling init +Steps to reproduce: +I have absolutely fresh Debian sid system (as of 2022-10-22). I create the following file on it: +```c +#include <stdio.h> + +int +main () +{ + printf ("a\n"); + printf ("b\n"); + for (;;); +} +``` + +Then I compile it so: `gcc -static -g a.c`. Result is saved as `/root/a.out`. Then I run `sync; echo 3 > /proc/sys/vm/drop_caches; sync` to make sure this `/root/a.out` actually got to disk. + +Then I start the host system inside of qemu using well-known `-snapshot /dev/sda` trick. Exact command is here: + +```bash +qemu-system-x86_64 -daemonize -m 300M -s -S -kernel /vmlinuz -initrd /initrd.img -snapshot -append "root=/dev/sda init=/root/a.out" -drive file=/dev/sda,format=raw +``` + +(As you guessed, my disk has no partitions, it directly stores ext4 filesystem.) + +Then I type on host `gdb ./a.out`. And then inside of gdb I type `target remote localhost:1234`, then `br 7` (line 7 is `printf ("b\n")`, then `c`. Then guest OS boots and reaches init (i. e. `/root/a.out`). And then gdb actually pauses on line 7. I. e. everything works! + +But if I add `-enable-kvm` to qemu command line OR remove `-static` from gcc command line, then breakpoint doesn't work, i. e. gdb doesn't pause on breakpoint, the execution continues and the execution fails to infinite loop. diff --git a/results/classifier/deepseek-2/output/hypervisor/1275 b/results/classifier/deepseek-2/output/hypervisor/1275 new file mode 100644 index 000000000..b3ed1606c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1275 @@ -0,0 +1,10 @@ + +javac command stuck forever in qemu vm which does not use hardware virtualization +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1278166 b/results/classifier/deepseek-2/output/hypervisor/1278166 new file mode 100644 index 000000000..0220ebed9 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1278166 @@ -0,0 +1,4 @@ + +Last commit to exec.c causes BSOD installing WinXP on i386-softmmu + +The last commit to exec.c (360e607b88a23d378f6efaa769c76d26f538234d), causes a BSOD when trying to install a 32bit Windows XP SP-3 image using the pure emulation version of i386-softmmu. A checkout of the previous version of the file (commited in 0169c511554cb0014a00290b0d3d26c31a49818f) solves the problem. Nevertheless, this last commit was intented to solve a BSOD when Xen was used as a hypervisor. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1280961 b/results/classifier/deepseek-2/output/hypervisor/1280961 new file mode 100644 index 000000000..e8314ffa2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1280961 @@ -0,0 +1,6 @@ + +editing the file when mount the file system using 9pfs. it will report fsync failed. + + I have get a fsync error when I use the 9pfs on the kvm guest. it appears when I use vi editor and sysbench. I have not found the reason yet. can you tell something about it? the attache is the picture. and there is no any log which I can provide. + + My qemu version is qemu-kvm-0.13.0, and my host linux distributions is 2.6.32-431.el6.x86_64 and the guest vm is the same version which enable 9pfs and 9pnet support. I use the string of "mount -t 9p -o trans=virtio test_mount /tmp/shared/ -oversion=9p2000.L,posixacl" to get the file system. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1288385 b/results/classifier/deepseek-2/output/hypervisor/1288385 new file mode 100644 index 000000000..e3a2e5639 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1288385 @@ -0,0 +1,65 @@ + +VFIO passthrough causes assertation failure + +Since commit 5e95494380ec I am no longer able to passthrough my Nvidia GTX 770 using VFIO. Qemu terminates with: + +qemu-system-x86_64: hw/pci/pcie.c:240: pcie_cap_slot_hotplug_common: Assertion `((pci_dev->devfn) & 0x07) == 0' failed. + +Above output was generated using commit f55ea6297cc0. + + +Lspci of the vga card: + +01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 770] (rev a1) + Subsystem: Gigabyte Technology Co., Ltd Device 360c + Kernel driver in use: vfio-pci +01:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1) + Subsystem: Gigabyte Technology Co., Ltd Device 360c + Kernel driver in use: vfio-pci + + +Commandline used to start qemu: + +qemu-system-x86_64 -machine accel=kvm \ + -nodefaults \ + -name VFIO-Test \ + -machine q35 \ + -cpu host \ + -smp 1 \ + -enable-kvm \ + -m 1024 \ + -k de \ + -vga none \ + -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ + -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ + -device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 \ + -rtc base=utc \ + -boot order=d \ + -device ide-cd,drive=drive-cd-disk1,id=cd-disk1,unit=0 \ + -drive file=/home/bluebird/Downloads/systemrescuecd-x86-4.0.0.iso,if=none,id=drive-cd-disk1,media=cdrom \ + -nographic + + +Full output of git bisect: + +5e95494380ecf83c97d28f72134ab45e0cace8f9 is the first bad commit +commit 5e95494380ecf83c97d28f72134ab45e0cace8f9 +Author: Igor Mammedov <email address hidden> +Date: Wed Feb 5 16:36:52 2014 +0100 + + hw/pci: switch to a generic hotplug handling for PCIDevice + + make qdev_unplug()/device_set_realized() to call hotplug handler's + plug/unplug methods if available and remove not needed anymore + hot(un)plug handling from PCIDevice. + + In case if hotplug handler is not available, revert to the legacy + hotplug method for compatibility with not yet converted buses. + + Signed-off-by: Igor Mammedov <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + +:040000 040000 9bdab0d75fbc9be4fe2e4274e58e0cdcd347ac7e d6d6294ea9c06e80a0fc8fcabd6345dfae5137ad M hw +:040000 040000 d064d75ca8b8f169c41eee2683082e8f9104e968 f2abbf9bee754ada0f49135968455fd1a69b2186 M include +:040000 040000 c515daff6c77f9bd2cc32873be4c5c3a1c20cbb9 c506f5587afe8f7ee129a7ca6e3ae2e5118254f9 M tests \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1297 b/results/classifier/deepseek-2/output/hypervisor/1297 new file mode 100644 index 000000000..265b35ee4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1297 @@ -0,0 +1,2 @@ + +qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) diff --git a/results/classifier/deepseek-2/output/hypervisor/1299858 b/results/classifier/deepseek-2/output/hypervisor/1299858 new file mode 100644 index 000000000..f6b95d8f5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1299858 @@ -0,0 +1,10 @@ + +qemu all apps crash on OS X 10.6.8 + +qemu-2.0.0-rc0 (and 1.7.1) crashes with SIGABORT in all apps when configured with --with-coroutine=sigaltstack (which is what configure selects by default) but all run fine if configured with --with-coroutine=gthread. + +Crash is at line 253 (last line of Coroutine *qemu_coroutine_new(void)) in coroutine-sigaltstack.c in 2.0.0-rc0 tarball. + +Platform is OS X 10.6.8 (Darwin Kernel Version 10.8.0), compiler gcc 4.2.1 + +Sorry for the sparse report but I'm short on time today. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1300021 b/results/classifier/deepseek-2/output/hypervisor/1300021 new file mode 100644 index 000000000..bb5e03eae --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1300021 @@ -0,0 +1,5 @@ + +after loadvm the system clock isn't current time + +hi, +when i load a snapshot of month ago using "loadvm name"command, the vm system time is past time,not recover current time. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1303926 b/results/classifier/deepseek-2/output/hypervisor/1303926 new file mode 100644 index 000000000..d35df1529 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1303926 @@ -0,0 +1,25 @@ + +qemu-system-x86_64 crashed with SIGABRT + +I've been getting this periodically since my upgrade to qemu 2.0 in trusty this morning. + +ProblemType: Crash +DistroRelease: Ubuntu 14.04 +Package: qemu-system-x86 2.0.0~rc1+dfsg-0ubuntu1 +ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8 +Uname: Linux 3.13.0-23-generic x86_64 +ApportVersion: 2.14.1-0ubuntu1 +Architecture: amd64 +Date: Mon Apr 7 13:31:53 2014 +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2013-11-26 (131 days ago) +InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1) +ProcEnviron: PATH=(custom, no user) +Registers: No symbol table is loaded. Use the "file" command. +Signal: 6 +SourcePackage: qemu +StacktraceTop: + +Title: qemu-system-x86_64 crashed with SIGABRT +UpgradeStatus: Upgraded to trusty on 2014-01-17 (79 days ago) +UserGroups: \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1304 b/results/classifier/deepseek-2/output/hypervisor/1304 new file mode 100644 index 000000000..2b7fbbfae --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1307656 b/results/classifier/deepseek-2/output/hypervisor/1307656 new file mode 100644 index 000000000..d2ffa269b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1307656 @@ -0,0 +1,16 @@ + +qemu segfault when starting virt-manager + +libvirtd 1.2.3 +virt-manager 1.0.1 +qemu 1.7.92 (2.0.0-rc2) + +1. Initially virt-manager is NOT running + +2. I start a VM manually using "virsh start ...", causing a qemu instance to be run as + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name Zeus_Virtualized -S -machine pc-i440fx-2.0,accel=kvm,usb=off -cpu Penryn -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 6384b4d2-1c58-4595-bce2-b248230e2c9c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Zeus_Virtualized.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_USBStick.qcow2,if=none,id=drive-usb-disk0,format=qcow2 -device usb-storage,drive=drive-usb-disk0,id=usb-disk0,removable=off -drive file=/home/pief/isos/openSUSE-13.1-DVD-x86_64.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_HDD1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_HDD2.qcow2,if=none,id=drive-virtio-disk1,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_SSD.qcow2,if=none,id=drive-virtio-disk2,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk2,id=virtio-disk2,bootindex=2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 + +3. I start virt-manager (just starting it, nothing special). + +4. The qemu instance segfaults with the attached backtrace. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1308341 b/results/classifier/deepseek-2/output/hypervisor/1308341 new file mode 100644 index 000000000..c09748c1f --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1317603 b/results/classifier/deepseek-2/output/hypervisor/1317603 new file mode 100644 index 000000000..702379abb --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1318091 b/results/classifier/deepseek-2/output/hypervisor/1318091 new file mode 100644 index 000000000..0dee74c9d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1318091 @@ -0,0 +1,40 @@ + +Perfctr MSRs not available to Guest OS on AMD Phenom II + +The AMD Phenom(tm) II X4 965 Processor (family 16, model 4, stepping 3) has the 4 architecturally supported perf counters at MSRs. The selectors are c001000-c001003, and the counters are c001004-c001007. I've verified that the MSRs are there and working by manually setting the MSRs with msr-tools to count cycles. + +The processor does not support the extended perfctr or the perfctr_nb. These are in cpuid leaf 8000_0001. Qemu also sees that these cpuid flags are not set, when I try launching with -cpu host,perfctr_core,check. However, this flag is only for the extended perfctr MSRs, which also happen to map the original four counters at c0010200. + +When I run a Guest OS, that OS is unable to use the perf counter registers from c001000-7. rdmsr and wrmsr complete, but the results are always 0. By contrast, a wrmsr to one of the c0010200 registers causes a general protection fault (as it should, since those aren't supported). + +Kernel: 3.14.0-gentoo +Qemu: 2.0.0 (gentoo) and also with 2.0.50 (commit 06b4f00d5) +Qemu command: qemu-system-x86_64 -enable-kvm -cpu host -smp 8 -m 1024 -nographic -monitor /dev/pts/4 mnt/hdd.img +cat /proc/cpuinfo: +processor : 3 +vendor_id : AuthenticAMD +cpu family : 16 +model : 4 +model name : AMD Phenom(tm) II X4 965 Processor +stepping : 3 +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 4 +core id : 3 +cpu cores : 4 +apicid : 3 +initial apicid : 3 +fpu : yes +fpu_exception : yes +cpuid level : 5 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save +bogomips : 6803.79 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate + +thanks. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1318474 b/results/classifier/deepseek-2/output/hypervisor/1318474 new file mode 100644 index 000000000..d0dc8024c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1318474 @@ -0,0 +1,14 @@ + +QEMU update causes Windows reactivation + +After updating QEMU the guest OS's detect new hardware. As a result any Windows OS sees it as a significant change in hardware and require a reactivation. + +Host OS: Ubuntu 14.04 64-bit + +Guest OS's: +Windows Server 2003 R2 Enterprise +Windows Server 2008 R2 Enterprise +Windows Server 2008 R2 Web +Windows Server 2008 R2 Data Center + +QEMU version: 2.0.0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1318746 b/results/classifier/deepseek-2/output/hypervisor/1318746 new file mode 100644 index 000000000..21d0ce4a7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1318746 @@ -0,0 +1,27 @@ + +qemu Windows 7 BSOD when using hv-time + +When I use hv-time sub option and run CPU-Z or 3DMark (Physics Test) the Windiws 7 guest stops with BSOD (SYSTEM_SERVICE_EXCEPTION). It can be easily reproduced by running CPU-Z. It will fail every second or third time you execute CPU-Z and fail during "PCI detection". If I disable hv-time I can run CPU-Z and 3DMark (Physics Test) without any problems. QEMU was called with the following options: + +/usr/bin/taskset -c 4,5,6,7 /usr/bin/qemu-system-x86_64 \ + -machine q35,accel=kvm,kernel_irqchip=on \ + -enable-kvm \ + -serial none \ + -parallel none \ + -monitor none \ + -vga std \ + -boot order=dc \ + -cpu host,hv-time \ + -smp cores=4,threads=1,sockets=1 \ + -m 8192 \ + -k de \ + -rtc base=localtime \ + -drive file=/srv/kvm/maggie-drive0.img,id=drive0,if=none,cache=none,aio=threads \ + -mon chardev=monitor0 \ + -chardev socket,id=monitor0,path=/tmp/maggie.monitor,nowait,server \ + -netdev tap,id=net0,vhost=on,helper=/usr/lib/qemu/qemu-bridge-helper \ + -device virtio-net-pci,netdev=net0,mac=00:00:00:02:01:01 \ + -device virtio-blk-pci,drive=drive0,ioeventfd=on \ + -device ioh3420,bus=pcie.0,id=pcie0,port=1,chassis=1,multifunction=on + +I've removed the VFIO PCI passthrough line of my GPU to make reproduction easier. In any case it happens in both scenarios so VGA passthrough is not the root cause. It happens with linux-3.15-rc5 and linux-3.14.3 with patch from commit mentioned at https://bugzilla.kernel.org/show_bug.cgi?id=73721#c3 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1324727 b/results/classifier/deepseek-2/output/hypervisor/1324727 new file mode 100644 index 000000000..27335d301 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1324727 @@ -0,0 +1,30 @@ + +qemu-system-arm segfaults without KVM on ARM + +I'm running on Odroid-XU, Debian Jessie armhf +qemu built from today's head d7d3d6092cb7edc75dc49fb90c86dd5425ab4805 + +sudo qemu-system-arm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id=foo -device virtio-blk-device,drive=foo -netdev user,id=user.0 -device virtio-net-device,netdev=user.0 -nographic -append 'root=/dev/vda rw console=ttyAMA0 rootwait' -kernel /usr/src/build/arm/linux-guest/arch/arm/boot/zImage -dtb a15x2.dtb +audio: Could not init `oss' audio driver +Uncompressing Linux... done, booting the kernel. +Segmentation fault + +If I run under GDB, the linux guest instance panics or hangs -- the behaviour is variable run to run. + +If I do: +sudo qemu-system-arm --enable-kvm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id=foo -device virtio-blk-device,drive=foo -netdev user,id=user.0 -device virtio-net-device,netdev=user.0 -nographic -append 'root=/dev/vda rw console=ttyAMA0 rootwait' -kernel /usr/src/build/arm/linux-guest/arch/arm/boot/zImage -dtb a15x2.dtb + +then the guest boots as expected. + +I tried to get a backtrace by allowinghte SEGV to dump core, and using gdb to inspect it: +Core was generated by `qemu-system-arm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id='. +Program terminated with signal 11, Segmentation fault. +#0 0xb53399c0 in ?? () +(gdb) bt +#0 0xb53399c0 in ?? () +Cannot access memory at address 0x28 +#1 0x0016d87e in cpu_tb_exec ( + tb_ptr=0xc786fe90 <Address 0xc786fe90 out of bounds>, cpu=0x24450d8) + at /mnt/qemu/cpu-exec.c:67 +#2 cpu_arm_exec (env=<optimized out>) at /mnt/qemu/cpu-exec.c:642 +#3 0x00000000 in ?? () \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1329956 b/results/classifier/deepseek-2/output/hypervisor/1329956 new file mode 100644 index 000000000..7b720d6a2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1329956 @@ -0,0 +1,21 @@ + +multi-core FreeBSD guest hangs after warm reboot + +On some Linux KVM hosts in our environment, FreeBSD guests fail to reboot properly if they have more than one CPU (socket, core, and/or thread). They will boot fine the first time, but after issuing a "reboot" command via the OS the guest starts to boot but hangs during SMP initialization. Fully shutting down and restarting the guest works in all cases. + +The only meaningful difference between hosts with the problem and those without is the CPU. Hosts with Xeon E5-26xx v2 processors have the problem, including at least the "Intel(R) Xeon(R) CPU E5-2667 v2" and the "Intel(R) Xeon(R) CPU E5-2650 v2". +Hosts with any other CPU, including "Intel(R) Xeon(R) CPU E5-2650 0", "Intel(R) Xeon(R) CPU E5-2620 0", or "AMD Opteron(TM) Processor 6274" do not have the problem. Note the "v2" in the names of the problematic CPUs. + +On hosts with a "v2" Xeon, I can reproduce the problem under Linux kernel 3.10 or 3.12 and Qemu 1.7.0 or 2.0.0. + +The problem occurs with all currently-supported versions of FreeBSD, including 8.4, 9.2, 10.0 and 11-CURRENT. + +On a Linux KVM host with a "v2" Xeon, this command line is adequate to reproduce the problem: + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name bsdtest -m 512 -smp 2,sockets=1,cores=1,threads=2 -drive file=./20140613_FreeBSD_9.2-RELEASE_ufs.qcow2,if=none,id=drive0,format=qcow2 -device virtio-blk-pci,scsi=off,drive=drive0 -vnc 0.0.0.0:0 -net none + +I have tried many variations including different models of -machine and -cpu for the guest with no visible difference. + +A native FreeBSD installation on a host with a "v2" Xeon does not have the problem, nor do a paravirtualized FreeBSD guests under bhyve (the BSD legacy-free hypervisor) using the same FreeBSD disk images as on the Linux hosts. So it seems unlikely the cause is on the FreeBSD side of things. + +I would greatly appreciate any feedback or developer attention to this. I am happy to provide additional details, test patches, etc. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1332 b/results/classifier/deepseek-2/output/hypervisor/1332 new file mode 100644 index 000000000..76a130895 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1332 @@ -0,0 +1,2 @@ + +qemu.log missing sstatus register on RISC-V diff --git a/results/classifier/deepseek-2/output/hypervisor/1333688 b/results/classifier/deepseek-2/output/hypervisor/1333688 new file mode 100644 index 000000000..064495cf1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1333688 @@ -0,0 +1,58 @@ + +vhost-user: VHOST_USER_SET_MEM_TABLE doesn't contain all regions + + + +vhost-user implementation doesn't provide information about all memory regions, +and in some cases client is not able to map buffer memory as he is missing +memory region information for specific address. + +Same thing is implemented properly for vhost-net. Below gdb outputs are +showing memory regions information provided to the vhost-net and vhost-user. + + + +==== memory regions information provided to vhost-net ==== + +(gdb) p/x hdev->mem->regions[0] +$21 = { + guest_phys_addr = 0x100000000, + memory_size = 0xc0000000, + userspace_addr = 0x2aab6ac00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[1] +$22 = { + guest_phys_addr = 0xfffc0000, + memory_size = 0x40000, + userspace_addr = 0x7ffff4a00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[2] +$23 = { + guest_phys_addr = 0x0, + memory_size = 0xa0000, + userspace_addr = 0x2aaaaac00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[3] +$24 = { + guest_phys_addr = 0xc0000, + memory_size = 0xbff40000, + userspace_addr = 0x2aaaaacc0000, + flags_padding = 0x0 +} +(gdb) + + +==== memory regions information provided to vhost-user ==== + +(gdb) p/x msg.memory.nregions +$28 = 0x1 +(gdb) p/x msg.memory.regions[0] +$29 = { + guest_phys_addr = 0x0, + memory_size = 0x180000000, + userspace_addr = 0x2aaaaac00000 +} +(gdb) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1344 b/results/classifier/deepseek-2/output/hypervisor/1344 new file mode 100644 index 000000000..99754dc7d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1344 @@ -0,0 +1,2 @@ + +custom kernel give me KVM internal error. Suberror: 4 diff --git a/results/classifier/deepseek-2/output/hypervisor/1348 b/results/classifier/deepseek-2/output/hypervisor/1348 new file mode 100644 index 000000000..ed1e9605f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1348 @@ -0,0 +1,2 @@ + +WIN10 MBR/SeaBIOS/CSM machine hangs at boot (same as #1115 https://gitlab.com/qemu-project/qemu/-/issues/1115 ) diff --git a/results/classifier/deepseek-2/output/hypervisor/1349277 b/results/classifier/deepseek-2/output/hypervisor/1349277 new file mode 100644 index 000000000..86aa055a0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1349277 @@ -0,0 +1,18 @@ + +AArch64 emulation ignores SPSel=0 when taking (or returning from) an exception at EL1 or greater + +The AArch64 emulation ignores SPSel=0 when: + +(1) taking an interrupt from an exception level greater than EL0 (e.g., EL1t), + +(2) returning from an exception (via ERET) to an exception level greater than EL0 (e.g., EL1t), with SPSR_ELx[SPSel]=0. + +The attached patch fixes the problem in my application. + +Background: + +I'm running a standalone application (toy OS) that is performing preemptive multithreading between threads running at EL1t, with exception handling / context switching occurring at EL1h. This bug causes the stack pointer to be corrupted in the threads running at EL1t (they end up with a version of the EL1h stack pointer (SP_EL1)). + +Occurs in: + qemu-2.1.0-rc1 (found in) + commit c60a57ff497667780132a3fcdc1500c83af5d5c0 (current master) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1351 b/results/classifier/deepseek-2/output/hypervisor/1351 new file mode 100644 index 000000000..0bff6191c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1351 @@ -0,0 +1,6 @@ + +qemu-system-x86_64 run win7 qcow2 got an exception +Description of problem: +when qemu-system-X86-64 run the win7 qcow2, qemu got an exception + +\*\* ERROR:../target/i386/tcg/sysemu/excp_helper.c:517:raise_stage2: code should not be reached Aborted (核心已转储) diff --git a/results/classifier/deepseek-2/output/hypervisor/1353947 b/results/classifier/deepseek-2/output/hypervisor/1353947 new file mode 100644 index 000000000..2f1caee6e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1353947 @@ -0,0 +1,15 @@ + +Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with CirrOS or Ubuntu 12.04 + +The issue observed when running an hypervisor with QEMU 2.0/libvirtd 1.2.2 +The VM network interface is attached to a PCI virtual function (SR-IOV). + +When we ran VM with guest OS CirrOS or Ubuntu 12.04 we observed an hipervisor hang shortly after the VM is loaded +We observed the same issue with Mellanox NIC and with Intel NIC + +We’ve tried few combinations of {GuestOS}X{Hypervisor} and we got the following findings: +When a hypervisor is running QEMU 1.5/libvirtd 1.1.1 - no issue observed +When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CirrOS and Ubuntu 12.04 guest OSes caused hypervisor hang +When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CentOS 6.4 and Ubuntu 13.10 - no issue observed + +The problematic guest OSes are with kernel versions ~3.2.y \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1354727 b/results/classifier/deepseek-2/output/hypervisor/1354727 new file mode 100644 index 000000000..27ebcc938 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1355644 b/results/classifier/deepseek-2/output/hypervisor/1355644 new file mode 100644 index 000000000..89d7cc6d9 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1355644 @@ -0,0 +1,18 @@ + +windows7 reboot bluesreen 0x0000005c + +I have met sevaral blue screen with 0x0000005c(0x0000010b,0x00000003,0x00000000,0x00000000) after windows7 reboot. +It always happens just before the windows iron animation appears. + +my qemu version is qemu-2.1.0 +my guest os is windows7 32bits sp1 + +my qemu commandline is +./x86_64-softmmu/qemu-system-x86_64 -m 2048 -hda system.inst -spice port=5940,disable-ticketing -monitor stdio --enable-kvm + +This bug doesn't happen always，and i don‘t know how to reproduce it. + +But i have a special way to produce such a bluescreen. +I set nmi dump on and set windows to collect dump file and set auto reboot after system fail on. +Then i send a nmi to guest, and then after collecting dump file , windows will auto reboot and then such a blue screen happens. +And this can be reproduced always. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1358619 b/results/classifier/deepseek-2/output/hypervisor/1358619 new file mode 100644 index 000000000..12cd4efae --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1358619 @@ -0,0 +1,94 @@ + +keep savevm/loadvm and migration cause snapshot crash + +--Version: qemu 2.1.0 public release +--OS: CentOS release 6.4 +--gcc: 4.4.7 + +Hi: + I found problems when doing some tests on qemu migration and savevm/loadvm. +On my experiment, a quest is migrated between two same host back and forth. +Source host would savevm after migration completed and incoming host loadvm before migration coming. + +image=./image/centos-1.qcow2 + +====Migration Part==== +qemu-system-x86_64 \ + -qmp tcp:$host_ip:4451,server,nowait \ + -drive file=$image \ + --enable-kvm \ + -monitor stdio \ + -m 8192 \ + -device virtio-net-pci,netdev=net0,mac=$mac \ + -netdev tap,id=net0,script=./qemu-ifup + +====Incoming Part==== +qemu-system-x86_64 \ + -qmp tcp:$host_ip:4451,server,nowait \ + -incoming tcp:0:4449 \ + --enable-kvm \ + -monitor stdio \ + -drive file=$image \ + -m 8192 \ + -device virtio-net-pci,netdev=net0,mac=$mac \ + -netdev tap,id=net0,script=./qemu-ifup + + +Command lines: + +host1 $: qemu-system-x86_64 ........ //migration part +host2 $: qemu-system-x86_64 ...incoming... //incoming part + +After finishing boot + +host1 (qemu) : migrate tcp:host2:4449 +host1 (qemu) : savevm s1 +host1 (qemu) : quit +host1 $: qemu-system-x86_64 ...incoming... //incoming part +host1 (qemu) : loadvm s1 + +host2 (qemu) : migrate tcp:host1:4449 +host2 (qemu) : savevm s2 +host2 (qemu) : quit +host2 $: qemu-system-x86_64 ...incoming... //incoming part +host2 (qemu) : loadvm s2 + +host1 (qemu) : migrate tcp:host2:4449 +host1 (qemu) : savevm s3 +host1 (qemu) : quit +host1 $: qemu-system-x86_64 ...incoming... //incoming part +host1 (qemu) : loadvm s3 + +I wish those operation can be success every time. +However problem happened irregularly when loadvm and error messages are not the same. + +host1 (qemu) : loadvm s3 +qcow2: Preventing invalid write on metadata (overlaps with active L1 table); image marked as corrupt. +Error -5 while activating snapshot 's3' on 'ide0-hd0' + +or + +host2 (qemu) : loadvm s2 +Error -22 while loading VM state + + +I have done some sample test on savevm/loadvm +On same host +(qemu) savevm test1 +(qemu) loadvm test1 +(qemu) savevm test2 +(qemu) loadvm test2 +(qemu) savevm test3 +(qemu) loadvm test3 +(qemu) savevm test4 +(qemu) loadvm test4 +(qemu) savevm test5 +(qemu) loadvm test5 +(qemu) savevm test6 +(qemu) loadvm test6 + +This is OK. No any problem. + + +Any idea? +I think it is related to migration. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1359394 b/results/classifier/deepseek-2/output/hypervisor/1359394 new file mode 100644 index 000000000..d3ea2c846 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1359394 @@ -0,0 +1,12 @@ + +virtio block device hangs after "virtio_blk virtio3: requests:id 0 is not a head!" + +The virtual machine is running block layer workloads, interrupted by unclean reboots (echo b > /proc/sysrq-trigger). Kernel version is 3.14. + +Sometimes, I get this message on boot: + +"virtio_blk virtio3: requests:id 0 is not a head!" + +Then, I/O to the virtio block devices just hangs. + +Unfortunately I don't have a test case and this is kind of hard to reproduce, but it seems related to having I/O in flight when the kernel is forced to reboot. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1362635 b/results/classifier/deepseek-2/output/hypervisor/1362635 new file mode 100644 index 000000000..0da1b419a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1362635 @@ -0,0 +1,43 @@ + +bdrv_read co-routine re-entered recursively + +calling bdrv_read in a loop leads to the follwing situation: + +bs->drv->bdrv_aio_readv is called, and finally calls bdrv_co_io_em_complete in other thread context. +there is a possibility of calling bdrv_co_io_em_complete before calling qemu_coroutine_yield in bdrv_co_io_em. And qemu fails with "co-routine re-entered recursively". + +static void bdrv_co_io_em_complete(void *opaque, int ret) +{ + CoroutineIOCompletion *co = opaque; + + co->ret = ret; + qemu_coroutine_enter(co->coroutine, NULL); +} + +static int coroutine_fn bdrv_co_io_em(BlockDriverState *bs, int64_t sector_num, + int nb_sectors, QEMUIOVector *iov, + bool is_write) +{ + CoroutineIOCompletion co = { + .coroutine = qemu_coroutine_self(), + }; + BlockDriverAIOCB *acb; + + if (is_write) { + acb = bs->drv->bdrv_aio_writev(bs, sector_num, iov, nb_sectors, + bdrv_co_io_em_complete, &co); + } else { + acb = bs->drv->bdrv_aio_readv(bs, sector_num, iov, nb_sectors, + bdrv_co_io_em_complete, &co); + } + + trace_bdrv_co_io_em(bs, sector_num, nb_sectors, is_write, acb); + if (!acb) { + return -EIO; + } + qemu_coroutine_yield(); + + return co.ret; +} + +is it a bug, or may be I don't understand something? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1385934 b/results/classifier/deepseek-2/output/hypervisor/1385934 new file mode 100644 index 000000000..23eff5097 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1385934 @@ -0,0 +1,29 @@ + +USB with passthrougth guest cannot enumerate USB host + +Following the guide at http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest +Qemu is launched with qemu-system-x86_64 /dev/vgstripe/kvm_wifi -enable-kvm -m 512 -k fr -net nic -net tap,ifname=tap1,script=/bin/ifup.script -kernel /usr/src/linux_git/arch/x86_64/boot/bzImage -append root=/dev/sda -usb -device usb-host,hostbus=1,hostaddr=6 +The USB device does not show and USB stack seems not working +On the guest: +dmesg |grep -i usb +[ 1.416966] hub 1-0:1.0: USB hub found +[ 1.420431] usbcore: registered new interface driver usb-storage +[ 1.445374] usbcore: registered new interface driver usbhid +[ 1.446839] usbhid: USB HID core driver +[ 1.863226] usb 1-1: new low-speed USB device number 2 using uhci_hcd +[ 2.126173] usb 1-1: Invalid ep0 maxpacket: 64 +[ 2.373161] usb 1-1: new low-speed USB device number 3 using uhci_hcd +[ 2.648112] usb 1-1: Invalid ep0 maxpacket: 64 +[ 2.892404] usb 1-1: new low-speed USB device number 4 using uhci_hcd +[ 2.913001] usb 1-1: Invalid ep0 maxpacket: 64 +[ 3.161367] usb 1-1: new low-speed USB device number 5 using uhci_hcd +[ 3.180070] usb 1-1: Invalid ep0 maxpacket: 64 +[ 3.181633] usb usb1-port1: unable to enumerate USB device +lsusb +Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub + +On the host: +lsusb +Bus 001 Device 006: ID 0457:0163 Silicon Integrated Systems Corp. SiS163U 802.11 Wireless LAN Adapter +qemu-system-x86_64 --version +QEMU emulator version 2.1.2, Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/139 b/results/classifier/deepseek-2/output/hypervisor/139 new file mode 100644 index 000000000..fb34c2570 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/139 @@ -0,0 +1,2 @@ + +kvm rbd driver (and maybe others, i.e. qcow2, qed and so on) does not report DISCARD-ZERO flag diff --git a/results/classifier/deepseek-2/output/hypervisor/1396 b/results/classifier/deepseek-2/output/hypervisor/1396 new file mode 100644 index 000000000..16443e1d9 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1398 b/results/classifier/deepseek-2/output/hypervisor/1398 new file mode 100644 index 000000000..f300e72d1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1398 @@ -0,0 +1,7 @@ + +Kernel Fault in primary space mode while using user ASCE emulating s390x with AlmaLinux release 9.1 (Lime Lynx) +Description of problem: +Happens twice during startup, however the system keeps running. +Steps to reproduce: +1. Install Alma Linux s390x on in KVM on x86_64 +2. Start KVM diff --git a/results/classifier/deepseek-2/output/hypervisor/1399191 b/results/classifier/deepseek-2/output/hypervisor/1399191 new file mode 100644 index 000000000..23df7bda2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1399191 @@ -0,0 +1,40 @@ + +Large VHDX image size + +We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). + +Why is that the VHDX generates large sized images for both the formats? + +The following commands were used to convert the vmdk image to VHDX format + +1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk Test-fixed.vhdx + +qemu-img info Test-fixed.vhdx +image: Test-fixed.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + + + +2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test-dynamic.vhdx + +qemu-img info Test-dynamic.vhdx +image: Test-dynamic.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + +We tried this with the following version of qemu +1. qemu-2.0.0 +2. qemu-2.1.2 +3. qemu-2.2.0-rc4 + + +Please let us know how to create compact VHDX images using qemu-img. +Thank you \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1401798 b/results/classifier/deepseek-2/output/hypervisor/1401798 new file mode 100644 index 000000000..e4c729977 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1401798 @@ -0,0 +1,26 @@ + +Qemu 2.2.0 savevm crash. + +qemu 2.1.2 is good. + +(gdb) bt +#0 0x00007ffff4aae445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007ffff4ab1bab in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x0000555555997951 in qcow2_cache_find_entry_to_replace (c=0x555556389780) at block/qcow2-cache.c:262 +#3 0x0000555555997a1a in qcow2_cache_do_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528, + read_from_disk=true) at block/qcow2-cache.c:285 +#4 0x0000555555997c45 in qcow2_cache_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528) + at block/qcow2-cache.c:331 +#5 0x0000555555991ca9 in l2_allocate (bs=0x5555563836f0, l1_index=1, table=0x7fffffffc5a0) at block/qcow2-cluster.c:247 +#6 0x000055555599290c in get_cluster_table (bs=0x5555563836f0, offset=549755813888, new_l2_table=0x7fffffffc610, + new_l2_index=0x7fffffffc62c) at block/qcow2-cluster.c:620 +#7 0x0000555555994213 in discard_single_l2 (bs=0x5555563836f0, offset=549755813888, nb_clusters=156, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1425 +#8 0x0000555555994491 in qcow2_discard_clusters (bs=0x5555563836f0, offset=549755813888, nb_sectors=638976, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1516 +#9 0x00005555559965c8 in qcow2_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/qcow2-snapshot.c:441 +#10 0x00005555559ad1ad in bdrv_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/snapshot.c:167 +#11 0x000055555565e90f in do_savevm (mon=0x555556992d20, qdict=0x5555599d5c00) at /vms/qemu/qemu-2.2.0/savevm.c:1126 + +(gdb) show args +Argument list to give program being debugged when it is started is "-name u1404-01 -S -machine pc,accel=kvm,usb=off -m 1024 -smp 2,sockets=2,cores=1,threads=1 -no-user-config -nodefaults -monitor stdio -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/vms/images/u1404-01.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=directsync -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6". \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1423528 b/results/classifier/deepseek-2/output/hypervisor/1423528 new file mode 100644 index 000000000..96edccc44 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1423528 @@ -0,0 +1,20 @@ + + setting unsupported timeout for i6300esb watchdog causes hw reset + +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778291 +Version: 2.1 + +systemd utilizes existing watchdog hardware and set's a 10min timer on reboot. +The i6300esb under qemu doesn't like such a timeout, and immediately resets the hardware: + +The last message one gets is +[ 9.402243] i6300esb: Unexpected close, not stopping watchdog! + + +The linked bug report contains information how this bug can easily be reproduced. +With any image using a recent enough systemd as PID 1 you should be able to reproduce it by running + +qemu-system-x86_64 -curses -enable-kvm -device i6300esb -watchdog-action reset -hda <image with systemd> + + +I'm uncertain if this is a qemu or kernel/driver bug. If the latter, please re-assign the bug as necessary. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1426472 b/results/classifier/deepseek-2/output/hypervisor/1426472 new file mode 100644 index 000000000..603d4554c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1426472 @@ -0,0 +1,28 @@ + +Recent regression: segfault on startup with -snapshot + +As of git revision 041ccc922ee474693a2869d4e3b59e920c739bc0, qemu segfaults on startup when I try to boot a hard disk image with the -snapshot option. + +To reproduce: + + wget http://wiki.qemu.org/download/linux-0.2.img.bz2 + bunzip2 linux-0.2.img.bz2 + qemu-system-i386 -hda linux-0.2.img -snapshot + +When I run this, qemu-system-i386 crashes with a segmentation fault. This is on a Debian 7 amd64 host. + +git bisect implicates the following commit: + +commit a464982499b2f637f6699e3d03e0a9d2e0b5288b +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 11 17:15:18 2015 +0100 + + rcu: run RCU callbacks under the BQL + + This needs to go away sooner or later, but one complication is the + complex VFIO data structures that are modified in instance_finalize. + Take a shortcut for now. + + Reviewed-by: Michael Roth <email address hidden> + Tested-by: Michael Roth <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1428352 b/results/classifier/deepseek-2/output/hypervisor/1428352 new file mode 100644 index 000000000..c4dd6358c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1428352 @@ -0,0 +1,45 @@ + +SYSRET instruction incorrectly implemented + +The Intel architecture manual states that when returning to user mode, the SYSRET instruction will re-load the stack selector (%ss) from the IA32_STAR model specific register using the following logic: + +SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *) + +Another description of the instruction behavior which shows the same logic in a slightly different form can also be found here: + +http://tptp.cc/mirrors/siyobik.info/instruction/SYSRET.html + +[...] + SS(SEL) = IA32_STAR[63:48] + 8; + SS(PL) = 0x3; +[...] + +In other words, the value of the %ss register is supposed to be loaded from bits 63:48 of the IA32_STAR model-specific register, incremented by 8, and then ORed with 3. ORing in the 3 sets the privilege level to 3 (user). This is done since SYSRET returns to user mode after a system call. + +However, helper_sysret() in target-i386/seg_helper.c does not do the "OR 3" step. The code looks like this: + + cpu_x86_load_seg_cache(env, R_SS, selector + 8, + 0, 0xffffffff, + DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | + DESC_S_MASK | (3 << DESC_DPL_SHIFT) | + DESC_W_MASK | DESC_A_MASK); + +It should look like this: + + cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3, + 0, 0xffffffff, + DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | + DESC_S_MASK | (3 << DESC_DPL_SHIFT) | + DESC_W_MASK | DESC_A_MASK); + +The code does correctly set the privilege level bits for the code selector register (%cs) but not for the stack selector (%ss). + +The effect of this is that when SYSRET returns control to the user-mode caller, %ss will be have the privilege level bits cleared. In my case, it went from 0x2b to 0x28. This caused a crash later: when the user-mode code was preempted by an interrupt, and the interrupt handler would do an IRET, a general protection fault would occur because the %ss value being loaded from the exception frame was not valid for user mode. (At least, I think that's what happened.) + +This behavior seems inconsistent with real hardware, and also appears to be wrong with respect to the Intel documentation, so I'm pretty confident in calling this a bug. :) + +Note that this issue seems to have been around for a long time. I discovered it while using QEMU 2.2.0, but I happened to have the sources for QEMU 0.10.5, and the problem is there too (in os_helper.c). I am using FreeBSD/amd64 9.1-RELEASE as my host system, without KVM. + +The fix is fairly simple. I'm attaching a patch which worked for me. Using this fix, the code that I'm testing now behaves the same on the QEMU virtual machine as on real hardware. + +- Bill (<email address hidden>) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1429841 b/results/classifier/deepseek-2/output/hypervisor/1429841 new file mode 100644 index 000000000..243d5ec58 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1429841 @@ -0,0 +1,47 @@ + +error "rom: requested regions overlap" for NOLOAD sections + +command line: +qemu-system-arm -semihosting -nographic -monitor null -serial null -no-reboot -kernel build/fw/0HNFcomSLuP1_CUNIT.elf + +output: +rom: requested regions overlap (rom phdr #6: build/fw/0HNFcomSLuP1_CUNIT.elf. free=0x8001effc, addr=0x8001c000) +rom loading failed + +I checked the sections of the .elf file with arm-none-eabi-objdump -h: +Sections: +Idx Name Size VMA LMA File off Algn +... + 35 .marker_appli 00001000 801ae000 801ae000 00025000 2**0 + ALLOC + 36 .safe_data 00000014 80200000 8001b000 00020000 2**2 + CONTENTS, ALLOC, LOAD, DATA + 37 .safe_bss 00000488 80200020 8001b020 00020014 2**2 + ALLOC + 38 .marker_safe_data 00001000 80201000 8001c000 00029000 2**0 + ALLOC + 39 .data 000008cc 80202000 8001b600 00022000 2**3 + CONTENTS, ALLOC, LOAD, DATA + 40 .bss 0000312c 802028d0 8001bed0 000228cc 2**3 + ALLOC + 41 .marker_data 00001000 80206000 8001f600 00026000 2**0 + ALLOC + 42 .cunit 00010000 80300000 80119600 00028000 2**0 + ALLOC + 43 .marker_code 00001000 8001c000 8001c000 00024000 2**0 + ALLOC +... + +So I had a look where the values in the error message could come from: +0x8001c000: is the "LMA" value of section .marker_safe_data +0x8001effc: is "Size" + "LMA" of the .bss section (0x0000312c + 0x8001bed0) + +So it is correct that (regarding the "LMA" value) the .marker_safe_data section collides with .bss section. +But actually these sections have no "LOAD" attribute, so I would guess that their "LMA" should not be used anyway. +Those section should reside at their "VMA" addresses (0x802xxxxx) during runtime but they have no data to load. + +Or am I getting something completely wrong? +Should I give an additional option to qemu? + +I got this error with 2.0.0+dfsg-2ubuntu1.10 and 1.0.50-2012.03-0ubuntu2.1 +I didn't get this error (but others) with 0.10.2 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1434 b/results/classifier/deepseek-2/output/hypervisor/1434 new file mode 100644 index 000000000..0c74440c2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1434 @@ -0,0 +1,4 @@ + +Windows on ARM64 host support +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1456819 b/results/classifier/deepseek-2/output/hypervisor/1456819 new file mode 100644 index 000000000..c0e472cdb --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1460523 b/results/classifier/deepseek-2/output/hypervisor/1460523 new file mode 100644 index 000000000..700247fa8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1460523 @@ -0,0 +1,11 @@ + +target-arm/op_helper.c:424: bad assert + +/home/dcb/qemu/trunk/qemu/target-arm/op_helper.c: In function ‘helper_access_check_cp_reg’: +/home/dcb/qemu/trunk/qemu/target-arm/op_helper.c:424:52: error: comparison of constant ‘3’ with boolean expression is always false [-Werror=bool-compare] + assert(!arm_is_secure(env) && !arm_current_el(env) == 3); + ^ + +Maybe + + assert(!arm_is_secure(env) && arm_current_el(env) != 3); \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1463 b/results/classifier/deepseek-2/output/hypervisor/1463 new file mode 100644 index 000000000..798627bab --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1463 @@ -0,0 +1,42 @@ + +VM with ivshmem and host pci device does not boot +Description of problem: +The boot aborts early if ivshmem and host-pci devices are used at the same time. +Steps to reproduce: +1. use a recent host kernel => 6.1.8 +2. use qemu from bullseye-backports (7.2) +3. use a recent edk2 bios with 4M secure boot + SMM +4. add ivshmem with e.g.: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1 +5. add a host-pci device to the VM +6. try to boot he VM +Additional information: +Observations: +always add ivshmem with: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1 +- a) no host-pci device + edk2 with secure boot => works +- b) with host-pci device + non edk2 => works +- c) with host-pci device + edk2 with secure boot => does not work +- d) with host-pci device + edk2 with secure boot + but without ivshmem => works + + +I have compiled a debug version of qemu und added some prints to the linux kernel. + +Qemu log shows: +``` +2023-01-25T23:30:47.128716Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument +2023-01-25T23:30:47.128741Z qemu-system-x86_64: vfio_dma_map(0x55cee4bf7b20, 0x385000000000, 0x2000000, 0x7fd7253ff000) = -2 (No such file or directory) +qemu: hardware error: vfio: DMA mapping failed, unable to continue +``` + +Kernel log prints in vfio_iommu_iova_dma_valid@drivers/vfio/vfio_iommu_type1.c - if (start >= node->start && end <= node->end): +``` +[ 1156.241294] DEBUG valid 1048576 >= 0 && 2147483647 <= 4276092927 +[ 1156.269472] DEBUG valid 1048576 >= 0 && 2130706431 <= 4276092927 +[ 1156.477577] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927 +[ 1156.478889] DEBUG valid 3254779904 >= 0 && 3254845439 <= 4276092927 +[ 1156.481226] DEBUG valid 3254779904 >= 0 && 3255042047 <= 4276092927 +[ 1156.482864] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927 +[ 1156.502867] DEBUG valid 61916248539136 >= 0 && 61916282093567 <= 4276092927 +[ 1156.502870] DEBUG valid 61916248539136 >= 4277141504 && 61916282093567 <= 549755813887 +``` + +The vfio_dma_map ioctl request from qemu to the kernel seems to fail because 0x385000000000 from qemu is not in any iova range known by the kernel. diff --git a/results/classifier/deepseek-2/output/hypervisor/1465935 b/results/classifier/deepseek-2/output/hypervisor/1465935 new file mode 100644 index 000000000..3aeb080f0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1465935 @@ -0,0 +1,8 @@ + +kvm_irqchip_commit_routes: Assertion `ret == 0' failed + +Several my QEMU instances crashed, and in the qemu log, I can see this assertion failure, + + qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/kvm-all.c:984: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. + +The QEMU version is 2.0.0, HV OS is ubuntu 12.04, kernel 3.2.0-38. Guest OS is RHEL 6.3. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1469978 b/results/classifier/deepseek-2/output/hypervisor/1469978 new file mode 100644 index 000000000..9a4ed47f8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1469978 @@ -0,0 +1,34 @@ + +compile qemu use with KVM machine not supported + +I have to compile qemu 2.3.0 and 2.2.0. and install follow this. + ./configure --enable-kvm --target-list=x86_64-softmmu + make + make install +It's located in /usr/local/bin +I want to use qemu with KVM so I copy /usr/local/bin/qemu-system-x86_64 to /usr/bin + +and I run VMM for start my VM. + + + +---------------------------------------------------------------------------------------------------------------------------------------------------------------------- +Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6: Unsupported machine type +Use -machine help to list supported machines! + + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1162, in startup + self._backend.create() + File "/usr/lib/python2.7/dist-packages/libvirt.py", line 866, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: internal error: process exited while connecting to monitor: qemu-system-x86_64: -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6: Unsupported machine type +Use -machine help to list supported machines! + +---------------------------------------------------------------------------------------------------------------------------------------------------------------------- + +I can't use my VM except reinstall kvm, qemu-kvm. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1473 b/results/classifier/deepseek-2/output/hypervisor/1473 new file mode 100644 index 000000000..6ef3159f5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1473 @@ -0,0 +1,2 @@ + +how to run qemu with sgx feature enabled diff --git a/results/classifier/deepseek-2/output/hypervisor/1474 b/results/classifier/deepseek-2/output/hypervisor/1474 new file mode 100644 index 000000000..018244a81 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1477538 b/results/classifier/deepseek-2/output/hypervisor/1477538 new file mode 100644 index 000000000..c51122a19 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1477538 @@ -0,0 +1,57 @@ + +Windows QEMU Guest Agent VSS Provider service stops during qemu backup + +I’m currently implementing the QEMU Guest Agent on all my KVM Windows guests. + +I’m using the stable VirtIO drivers and Guest agent from Fedora: https://fedoraproject.org/wiki/Windows_Virtio_Drivers + +Both the stable and latest release do provide Qemu Windows Guest agent 7.0.0.10. + +After the Guest agent installation I initially received VSS events with ID 8194: + + Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. + +This is often caused by incorrect security settings in either the writer or requestor process. +Operation: + Gathering Writer Data +Context: + + Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220} + + Writer Name: System Writer + + Writer Instance ID: {6c777a34-53dd-4fb3-a4c9-b85d7e183e27} + + +I was able to fix this issue by adding local access permissions for the “Network Service” account at the Dcom security permissions: + +On the client computer from the Start Menu, select Run +The Run dialog opens. +In the Open field type dcomcnfg and click OK. +The Component Services dialog opens. +Expand Component Services, Computers, and My Computer. +Right-click My Computer and click Properties on the pop-up menu. +The My Computer Properties dialog opens. +Click the COM Security tab. +Under Access Permission click Edit Default. +The Access Permissions dialog opens. +From the Access Permissions dialog, add the "Network Service" account with Local Access allowed. +Close all open dialogs. + +Now an initial backup runs without any errors but this is causing the QEMU Guest Agent VSS Provider service to stop running without any error in the event log. + +As a result a second backup will cause an error: MSDTC Client 2 with event ID: 4879: + +MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system SERVERNAME. + +This is probably caused because the QEMU Guest Agent VSS Provider service isn’t running anymore. + +I can manually start the QEMU Guest Agent VSS Provider service but every backup is causing the service to stop. + +I’m seeing this behavior at all my Windows based guests running both Windows Server 2012 R2 and Windows Server 2008 R2. + + Since I can’t find any logging or troubleshooting possibilities for this particular service I'm open for suggestions how to troubleshoot this issue to receive detailed information about the reason why this services stops running during a backup. + + +qemu-server 3.4-3 amd64 +Guest agent 7.0.0.10 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/148 b/results/classifier/deepseek-2/output/hypervisor/148 new file mode 100644 index 000000000..8692bd2bb --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/148 @@ -0,0 +1,2 @@ + +Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM diff --git a/results/classifier/deepseek-2/output/hypervisor/1483070 b/results/classifier/deepseek-2/output/hypervisor/1483070 new file mode 100644 index 000000000..4c723d3b0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1483070 @@ -0,0 +1,20 @@ + +VIRTIO Sequential Write IOPS limits not working + +Root Problem: +IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. + +To confirm: +IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. +VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. + +Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): +virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. +virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. + +For Linux: +The issue is also apparent, tested on Ubuntu 14.04 + +On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 and 4) using multiple machines but all are 64bit intel. + +Even though the latest VIRTIO guest drivers fix the problem, the guest drivers shouldn't be able to ignore the limits the host puts in place or am I missing something?? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1484 b/results/classifier/deepseek-2/output/hypervisor/1484 new file mode 100644 index 000000000..756c10137 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1485180 b/results/classifier/deepseek-2/output/hypervisor/1485180 new file mode 100644 index 000000000..94d49de7b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1485180 @@ -0,0 +1,22 @@ + +Ctrl Alt G -- Multiple Virtual Machines + +I'm using Fedora 22. + +Firstly, what works: +A single VM instance, running Windows. Although, I am keeping this (GTK) window focused. + +What really fails: +If I have two running VM's, WIndows XP and Windows Vista: +1. I press Ctrl-Alt-G to get the focus. +2. That works first time. +3. Then I press Ctrl-Alt-G again. +4. Then Alt-Tab to the other machine (switching from XP to Vista, or back.) +5. Then press Ctrl-Alt-G to gain focus: +- Problem is that now the Ctrl-Alt-G, although showing in the title bar, only grabs the mouse, but NOT the keyboard. That is to say, whilst in Ctrl-Alt-G mode the second time, pressing Alt-Tab jumps back to the other VM! + +Pressing Alt-F4 quits!!!!!!!!!!!!! Regardless of whether Ctrl-Alt-G mode or not! +But only when running two VM's. + +Thanks +Misha \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/149 b/results/classifier/deepseek-2/output/hypervisor/149 new file mode 100644 index 000000000..16f63793e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/149 @@ -0,0 +1,2 @@ + +vmxnet3 unable to send IPv6 ESP packets diff --git a/results/classifier/deepseek-2/output/hypervisor/1493033 b/results/classifier/deepseek-2/output/hypervisor/1493033 new file mode 100644 index 000000000..2b2d0005f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1493033 @@ -0,0 +1,50 @@ + +memory leak/high memory usage with spice webdav feature + +This bug is being open due the comment: +https://bugs.freedesktop.org/show_bug.cgi?id=91350#c9 + +Description of problem: +When copying big files from client to guest, the memory usage in the host grows by about the size of the file. This is partially spice problem due the memory pool being able to increase as much as necessary without a limit which should be handled by the patches sent in the mailing list [0] + +[0] http://lists.freedesktop.org/archives/spice-devel/2015-August/021644.html + +At the same time, massif shows high memory usage by qemu as well [1] (output attached) + +[1] (peak) +->49.64% (267,580,319B) 0x308B89: malloc_and_trace (vl.c:2724) +| ->49.38% (266,167,561B) 0x67CE678: g_malloc (gmem.c:97) +| | ->49.03% (264,241,152B) 0x511D8E: qemu_coroutine_new (coroutine-ucontext.c:106) +| | | ->49.03% (264,241,152B) 0x510E24: qemu_coroutine_create (qemu-coroutine.c:74) +(...) + +The file being shared was a 320M ogv video. + +Version-Release number of selected component (if applicable): +QEMU emulator version 2.3.93 +SPICE and SPICE-GTK: from git master + +How reproducible: +100% + +Steps to Reproduce: +1-) build spice-gtk with --enable-webdav=yes +2-) enable webdav in your VM by following: +https://elmarco.fedorapeople.org/manual.html#_folder_sharing +3-) using remote-viewer with webdav patches, connects to a fedora guest +4-) Open nautilus, go to 'Browse Network' +5-) On remote-viewer, enable shared folder by File > Preferences > [X] Share folder +6-) The spice client folder should appear: Double-click to mount it. +7-) Check the memory of your qemu process +8-) Copy a big file (let's say, 300 MB) from the shared folder to local VM +9-) See the memory consumption of qemu grows by a lot; + +Actual results: +Memory usage grows during copy and is not freed + +Expected results: +Memory should have an upper limit to grow and should be freed after copy + +Additional info: +Also reported in Fedora/rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=1256376 +SPICE upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=91350 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1498144 b/results/classifier/deepseek-2/output/hypervisor/1498144 new file mode 100644 index 000000000..cec02914b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1498144 @@ -0,0 +1,30 @@ + + Failure booting hurd with qemu-system-i386 on ARM + +Trying to boot debian-hurd-20150320.img ends with: + +qemu-system-i386: qemu-coroutine-lock.c:91: qemu_co_queue_restart_all: Assertion `qemu_in_coroutine()' failed. + +Program received signal SIGABRT, Aborted. +__libc_do_syscall () + at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44 +44 ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory. +(gdb) bt +#0 __libc_do_syscall () + at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44 +#1 0xb6ef8f0e in __GI_raise (sig=sig@entry=6) + at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#2 0xb6efb766 in __GI_abort () at abort.c:89 +#3 0xb6ef4150 in __assert_fail_base ( + fmt=0x1 <error: Cannot access memory at address 0x1>, + assertion=0x7f89a234 "qemu_in_coroutine()", assertion@entry=0x0, + file=0x7f89da58 "qemu-coroutine-lock.c", file@entry=0xb5660000 "\001", + line=91, line@entry=3069931692, + function=function@entry=0x7f89ab78 "qemu_co_queue_restart_all") + at assert.c:92 +#4 0xb6ef41e6 in __GI___assert_fail (assertion=0x0, file=0xb5660000 "\001", + line=3069931692, function=0x7f89ab78 "qemu_co_queue_restart_all") + at assert.c:101 +#5 0x7f59a6b4 in ?? () + +I was using the same setup as in Bug 893208 (i.e git checkout from 2015-09-15) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1501 b/results/classifier/deepseek-2/output/hypervisor/1501 new file mode 100644 index 000000000..7e0296a9a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1501 @@ -0,0 +1,2 @@ + +IBM AIX 73 not supported under QEMU diff --git a/results/classifier/deepseek-2/output/hypervisor/1503031 b/results/classifier/deepseek-2/output/hypervisor/1503031 new file mode 100644 index 000000000..988be3055 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1503031 @@ -0,0 +1,12 @@ + +32-to-64-bit call gate unsupported in IA32e mode + +In particular, the lcall implementation doesn't support the 64-bit TSS. + +helper_lcall_protected (target-i386/seg_helper.c:1884) calls get_ss_esp_from_tss() on a call gate to a lower privilege level, which tries to extract a 32-bit ESP and 16-bit SS from the TSS. In IA32e mode (64-bit or compatibility mode), this instead grabs the lower 32-bits of the target RSP, and 16 of the upper bits as the SS. Additionally, several of the subsequent checks are incorrect (even if the correct stack pointer were extracted). + +This isn't a problem for interrupts since the interrupts are given their own implementation entirely, that uses get_rsp_from_tss() rather than get_ss_esp_from_tss(). + +I believe the missing logic is from the branch starting "ELSE (* current TSS is 64-bit *)" in the CALL pseudocode in the Intel manual (page 3-124 of the PDF I have). + +Reproduced at master (c0b520dfb8890294a9f8879f4759172900585995), and also as of a qemu built a year ago. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1505 b/results/classifier/deepseek-2/output/hypervisor/1505 new file mode 100644 index 000000000..ccf24bd59 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1505 @@ -0,0 +1,2 @@ + +guest agent: add --allow-rpcs / whitelist mode diff --git a/results/classifier/deepseek-2/output/hypervisor/1508405 b/results/classifier/deepseek-2/output/hypervisor/1508405 new file mode 100644 index 000000000..c5f1ed1d9 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1508405 @@ -0,0 +1,70 @@ + +qemu 2.4.0 with --enable-kvm hangs, takes 100% CPU + +When starting qemu-system-x86_64 from version 2.4.0 with --enable-kvm, it hangs and takes 100% CPU. The graphical display (SeaBIOS output) is not initialized. + +There have been multiple reports of this issue in the following thread: +https://bbs.archlinux.org/viewtopic.php?pid=1572405 + +There is no need to load a certain image, it already hangs with the following command: +qemu-system-x86_64 --enable-kvm + +There are three workarounds: +- Downgrading the kernel form 4.2.2 to 4.1.6 (according to the forum thread, have not tested this myself) +- Downgrading qemu to 2.3 (tested personally, works) +- passing -machine pc-i440fx-2.3 to qemu 2.4 (have not tested this myself, I will try that shortly) + +modules kvm and kvm_intel are loaded and rmmod && modprobing them does not change the situation + +I have an nvidia card and switching from official binary drivers to nouveau and back does not change the situation. + + +qemu is installed from Arch package. From the PKGBUILD you can see that is is built with the following configuration: +================================================================ +export ARFLAGS="rv" + export CFLAGS+=' -fPIC' + ./configure --prefix=/usr --sysconfdir=/etc --audio-drv-list='pa alsa sdl' \ + --python=/usr/bin/python2 --smbd=/usr/bin/smbd \ + --enable-docs --libexecdir=/usr/lib/qemu \ + --disable-gtk --enable-linux-aio --enable-seccomp \ + --enable-spice --localstatedir=/var \ + --enable-tpm \ + --enable-modules --enable-{rbd,glusterfs,libiscsi,curl} + make V=99 +================================================================ + +cpuinfo on my machine (for the first core only): + +================================================================ +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 30 +model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz +stepping : 5 +microcode : 0x7 +cpu MHz : 1333.000 +cache size : 8192 KB +physical id : 0 +siblings : 8 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +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 nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid +bugs : +bogomips : 3459.21 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +================================================================ + +Is there more information I can provide you with to help debug this problem? + +Thanks, + +cptG \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1511 b/results/classifier/deepseek-2/output/hypervisor/1511 new file mode 100644 index 000000000..91d8d49b7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1511 @@ -0,0 +1,2 @@ + +Please a CPU model for ABI version for x86_64 i386 according to x86-64 psABI diff --git a/results/classifier/deepseek-2/output/hypervisor/1516 b/results/classifier/deepseek-2/output/hypervisor/1516 new file mode 100644 index 000000000..d267e8ed4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1516 @@ -0,0 +1,40 @@ + +QEMU does not reload kernel image on guest reboot (direct kernel boot) +Description of problem: +I am using virtiofs as root filesystem with QEMU direct kernel boot. The kernel is loaded from the guests directory structure that is exported from the host. + +The problem is that QEMU does not reload the kernel image file from disk during a guest reboot. This means it is not possible to update the kernel from inside the guest and do a simple reboot to load it. A full power cycle of the guest is required to load the updated kernel image. +Steps to reproduce: +1. Migrate a Linux guest to virtiofs as root fs. +2. Enable QEMU direct kernel boot and point to guest's kernel in the exported root filesystem. +3. Boot. +4. Update the kernel inside the guest. Overwrite the existing kernel image +5. Issue `reboot` inside the guest. +6. When the guest reboots, the old kernel is still booted, even though the image file was overwritten. +7. Issue `poweroff` inside the guest. +8. Issue `virsh start <guest-vm>` +9. Now the new kernel image is booted. +Additional information: +XML: +``` +<type arch='x86_64' machine='pc-q35-7.0'>hvm</type> + <kernel>/media/vm/libvirt/images/alpine-q/root/boot/vmlinuz-virt</kernel> + <initrd>/media/vm/libvirt/images/alpine-q/root/boot/initramfs-virt</initrd> + <cmdline>rootfstype=virtiofs root=root rw</cmdline> + <boot dev='hd'/> + <bootmenu enable='no'/> + </os> + +... + + <filesystem type='mount' accessmode='passthrough'> + <driver type='virtiofs'/> + <binary path='/usr/libexec/virtiofsd' xattr='on'> + <cache mode='always'/> + <lock posix='on' flock='on'/> + </binary> + <source dir='/media/vm/libvirt/images/alpine-q/root'/> + <target dir='root'/> + <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> + </filesystem> +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/1524637 b/results/classifier/deepseek-2/output/hypervisor/1524637 new file mode 100644 index 000000000..25eebc48e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1524637 @@ -0,0 +1,16 @@ + +system_powerdown/system_reset not working when exec stop on hmp + +system_powerdown/system_reset stops working in qemu for centos kernels if KVM is enabled. + +qemu versioin: 2.4 +linux kernel versioin: 4.2.5 + +How to reproduce: + +1. qemu-system-x86_64 -enable-kvm -drive if=none,id=drive0,file=/media/sda5/image/fc21/fc21.raw -device virtio-blk-pci,drive=drive0,iothread=iothread0 -machine smm=off -object iothread,id=iothread0 -monitor stdio +2. Enter stop in the qemu console, we can see the vm is stopped. +3. Enter system_powerdown in the qemu console +4. Nothing happens. + +Can you please give a prompt or something else when the vm isn't allowed to powerdown or reset? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1525676 b/results/classifier/deepseek-2/output/hypervisor/1525676 new file mode 100644 index 000000000..a004143bb --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1525676 @@ -0,0 +1,36 @@ + +qemu runas and sandbox option incompatible, process will hang in futex after setgid + +With -runas [user] and -sandbox on, qemu process will fail in the process of dropping privileges. While setgid() is done (see below), setuid() is not attempted. Instead process blocks waiting for a futex never to come. + +[pid 21769] +++ killed by SIGSYS +++ +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] tgkill(21767, 21768, SIGRT_1 <unfinished ...> +[pid 21768] <... nanosleep resumed> {0, 7284187}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) +[pid 21768] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=21767, si_uid=0} --- +[pid 21768] setgid(100) = 0 +[pid 21768] futex(0x7f7f0f53fd1c, FUTEX_WAKE_PRIVATE, 1) = 0 +[pid 21768] rt_sigreturn() = -1 EINTR (Interrupted system call) +[pid 21768] nanosleep({0, 7284187}, <unfinished ...> +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] futex(0x7ffd5a9b6890, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...> +[pid 21768] <... nanosleep resumed> 0x7f7f0f53eb00) = 0 +[pid 21768] futex(0x55f52acd1f44, FUTEX_WAIT, 4294967295, NULL + +This bug might be addresses in the discussion/patchset http://qemu.11.n7.nabble.com/PATCH-Add-syscalls-for-runas-and-chroot-to-the-seccomp-sandbox-td359588.html + +# lsb_release -rd +Description: Ubuntu 15.10 +Release: 15.10 + +# apt-cache policy qemu-system-x86 +qemu-system-x86: + Installed: 1:2.3+dfsg-5ubuntu9.1 + Candidate: 1:2.3+dfsg-5ubuntu9.1 + Version table: + *** 1:2.3+dfsg-5ubuntu9.1 0 + 500 http://archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages + 500 http://archive.ubuntu.com/ubuntu/ wily-security/main amd64 Packages + 100 /var/lib/dpkg/status + 1:2.3+dfsg-5ubuntu9 0 + 500 http://archive.ubuntu.com/ubuntu/ wily/main amd64 Packages \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1529 b/results/classifier/deepseek-2/output/hypervisor/1529 new file mode 100644 index 000000000..9ee1563db --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1529 @@ -0,0 +1,2 @@ + +Documentation refers to Windows Hypervisor Platform as wphx instead of whpx diff --git a/results/classifier/deepseek-2/output/hypervisor/1529187 b/results/classifier/deepseek-2/output/hypervisor/1529187 new file mode 100644 index 000000000..90e12a763 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1529187 @@ -0,0 +1,37 @@ + +vfio passtrhough fails at 'No available IOMMU models' on Intel BDW-EP platform + +Environment: + ------------ + Host OS (ia32/ia32e/IA64): ia32e + Guest OS (ia32/ia32e/IA64): ia32e + Guest OS Type (Linux/Windows): linux + kvm.git Commit: da3f7ca3 + qemu.git Commit: 38a762fe + Host Kernel Version: 4.4.0-rc2 + Hardware: BDW EP (Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz, Grantley-EP) + +Bug description: + -------------------------- + when create guest with vt-d assignment using vfio-pci driver, the guest can not be created. +Warning 'No available IOMMU models' + + +Reproduce steps: + ---------------- + 1. bind device to vfio-pci driver + 2. qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -device vfio-pci,host=81:00.0 -net none -drive file=rhel7u2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 + +Current result: + ---------------- + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: No available IOMMU models + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to setup container for group 41 + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to get group 41 + qemu-system-x86_64: -device vfio-pci,host=81:00.0: Device initialization failed + +Expected result: + ---------------- + guest can be created +Basic root-causing log: + ---------------------- + \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1533848 b/results/classifier/deepseek-2/output/hypervisor/1533848 new file mode 100644 index 000000000..c21df5060 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1533848 @@ -0,0 +1,4 @@ + +A workaround for Windows 7 ACPI SLIC table behavior when used with OVMF + +When OVMF is used, Windows 7 refuses to read SLIC ACPI table, passed via -acpitable option, because it expects oem id and oem table id to match in SLIC, XSDT, RSDT, FADT. There's a detailed discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=1248758 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1535 b/results/classifier/deepseek-2/output/hypervisor/1535 new file mode 100644 index 000000000..39e379e30 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1549298 b/results/classifier/deepseek-2/output/hypervisor/1549298 new file mode 100644 index 000000000..53b45fcc1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1549298 @@ -0,0 +1,14 @@ + +Add missing MSRs for powertop + +I reported this same bug on the powertop bugtracker [1] because I think both projects need to change something here. + +When running powertop it crashes and prints: + + unknown op '{' + read_msr cpu0 0xe8 : Input/output error + +It seems that powertop is trying to access model specific registers and because qemu doesn't emulate them it crashes. +Clearly powertop shouldn't crash in such case but I think it would also be better if qemu could add support for these registers. + +1: https://app.devzing.com/powertopbugs/bugzilla/show_bug.cgi?id=4 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/155 b/results/classifier/deepseek-2/output/hypervisor/155 new file mode 100644 index 000000000..bd929a457 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/155 @@ -0,0 +1,2 @@ + +MMX emulation is missing on HVF Acceleration diff --git a/results/classifier/deepseek-2/output/hypervisor/1550 b/results/classifier/deepseek-2/output/hypervisor/1550 new file mode 100644 index 000000000..052a2b13d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1550 @@ -0,0 +1,17 @@ + +Crazy mouse movement when passing `-M pc,vmport=off -accel kvm -vga virtio` at the same time +Description of problem: +The mouse cursor is unusable in an x86 guest (disappears, jumps around like crazy) in a graphical environment when `-M pc,vmport=off -accel kvm -vga virtio` is given at the same time. +Steps to reproduce: +1. Download https://download.manjaro.org/xfce/22.0.5/manjaro-xfce-22.0.5-230316-linux61.iso +2. Start above command +3. Wait until the graphical desktop appears +4. Click inside the window and move the mouse + +-> Mouse cursor disappears or jumps around like crazy +Additional information: +If vmport=off is **not** passed, at some point during startup (before graphical login manager appears) the guest switches to use vmmouse from PS/2 mouse. There it also requests usage of absolute input coordinates (VMMOUSE_REQUEST_ABSOLUTE). This code path works normal. Therefore the culprit might be in the guest. + +Another way to reproduce the issue is to use -accel whpx under Windows host (no need to pass vmport=off there). It can be observed that the same guest doesn't attempt to switch to vmmouse there, just like passing vmport=off under Linux. + +The problem does not exist on Linux host when -accel tcg is used in which case the guest doesn't attempt to switch to vmmouse. diff --git a/results/classifier/deepseek-2/output/hypervisor/1553760 b/results/classifier/deepseek-2/output/hypervisor/1553760 new file mode 100644 index 000000000..d18802761 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1556 b/results/classifier/deepseek-2/output/hypervisor/1556 new file mode 100644 index 000000000..0e48bfcaf --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1556 @@ -0,0 +1,36 @@ + +RISCV HGATP CSR writes incorrect +Description of problem: +Issue with CSR writes/reads of SATP and HGATP. +Starting with SATP, in file `qemu/target/riscv/csr.c` the function write_satp has the following code snippet: + +```C + if (riscv_cpu_mxl(env) == MXL_RV32) { + vm = validate_vm(env, get_field(val, SATP32_MODE)); + mask = (val ^ env->satp) & (SATP32_MODE | SATP32_ASID | SATP32_PPN); + } else { + vm = validate_vm(env, get_field(val, SATP64_MODE)); + mask = (val ^ env->satp) & (SATP64_MODE | SATP64_ASID | SATP64_PPN); + } + + if (vm && mask) { + if (env->priv == PRV_S && get_field(env->mstatus, MSTATUS_TVM)) { + return RISCV_EXCP_ILLEGAL_INST; +``` +The potential problem I see in the code is that a CSR write which is either illegal or the same as what was previously in the CSR will not yield an illegal instruction. This potential issue could be simple to fix by simply moving the TVM check outside the vm && mask if-statement. +EDIT: I haven't been able to replicate this. Maybe there is code somewhere else which guards against this situation, I'll leave this comment here anyway just to get an extra pair of eyes on this code. + +For writes to hgatp (in the same source file) the value provided to the function is simply written directly to hgatp. +``` +static RISCVException write_hgatp(CPURISCVState *env, int csrno, + target_ulong val) +{ + env->hgatp = val; + return RISCV_EXCP_NONE; +} +``` +This can not be correct, the specification for example states `"A write to hgatp with an unsupported MODE value is not ignored as it is for satp. Instead, the fields of hgatp are WARL in the normal way, when so indicated."` Furthermore, there is also a restriction on the ppn field saying that ppn[1:0] must be 0. Finally when reading hgatp the tvm flag is not taken into consideration at all. +Additional information: +The provided binary should be able to replicate the issue. The error regarding num_unexp_trap can be disregarded in this case, normally I break a test directly on an assertion failure but I didn't this time which is why the counter is increasing. + +[main](/uploads/31ef3bc424d63097177cba3579d9b411/main) diff --git a/results/classifier/deepseek-2/output/hypervisor/1557033 b/results/classifier/deepseek-2/output/hypervisor/1557033 new file mode 100644 index 000000000..3078928a5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1557033 @@ -0,0 +1,17 @@ + +Persistent malfunction after guest shutdown/reboot + +Running the VM the first time after the host has booted up is completely fine, no issues at all. However, after shutting down or restarting the VM, certain problems occur. In the Windows 10 VM, it may throw a SYSTEM_THREAD_EXCEPTION error on bootup, and other times it simply won't use the VirtIO drive. Before the latest update of QEMU 2.5.0, I have had no problems. + +Recently, I've also downgraded my kernel in order to solve some problems related to Haswell. This is probably the same time I've got the 2.5.0 update. When I did this, I could no longer boot into my main image due to similar problems. I've had to also update the VirtIO storage driver with a new image installation. Before I figured that everything worked fine on a host reboot, the installer would spit out an error that it could not modify the partitions of the drive. Everything else worked fine with SATA or IDE configuration, but not VirtIO. I shouldn't need to restart my computer after shutting down the computer. + +I've tried using QEMU with the latest Linux kernel (4.4.x) with the exact same result. + +Here is what I have configured: +- Arch Linux with linux-lts (4.1.19-1-lts) +- QEMU 2.5.0 +- VirtIO drivers v 0.1.113 +- Windows 10 from MSDN +- vfio PCI Passthrough of NVIDIA 970 + +I'm not sure how to get any more logs so if you need more info I'll be glad to provide it \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1558 b/results/classifier/deepseek-2/output/hypervisor/1558 new file mode 100644 index 000000000..1c1448dda --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1562 b/results/classifier/deepseek-2/output/hypervisor/1562 new file mode 100644 index 000000000..891d90c35 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1562 @@ -0,0 +1,130 @@ + +qemu live migration with compression ( zstd or zlib ) in same server always(100% reproduce) failed (recevied ram page flag 0x0) +Description of problem: + +Steps to reproduce: +1. live migration with compress mode in same server +2. src: qemu-system-x86_64 -cpu Cascadelake-Server-v4 -smp 10 -enable-kvm -m 50G -nographic -serial telnet:localhost:4321,server,nowait -nic tap,ifname=tap0,script=no,downscript=no CentOS-Stream-GenericCloud-9-20230123.0.x86_64_test_0.qcow2 + +``` + QEMU 7.2.91 monitor - type 'help' for more information +(qemu) migrate_set_capability compress on +(qemu) migrate_set_parameter multifd-compression zstd +(qemu) info migrate_capabilities +xbzrle: off +rdma-pin-all: off +auto-converge: off +zero-blocks: off +compress: on +events: off +postcopy-ram: off +x-colo: off +release-ram: off +block: off +return-path: off +pause-before-switchover: off +multifd: off +dirty-bitmaps: off +postcopy-blocktime: off +late-block-activate: off +x-ignore-shared: off +validate-uuid: off +background-snapshot: off +zero-copy-send: off +postcopy-preempt: off +(qemu) info migrate_parameters +announce-initial: 50 ms +announce-max: 550 ms +announce-rounds: 5 +announce-step: 100 ms +compress-level: 1 +compress-threads: 8 +compress-wait-thread: on +decompress-threads: 2 +throttle-trigger-threshold: 50 +cpu-throttle-initial: 20 +cpu-throttle-increment: 10 +cpu-throttle-tailslow: off +max-cpu-throttle: 99 +tls-creds: '' +tls-hostname: '' +max-bandwidth: 134217728 bytes/second +downtime-limit: 300 ms +x-checkpoint-delay: 20000 ms +block-incremental: off +multifd-channels: 2 +multifd-compression: zstd +xbzrle-cache-size: 67108864 bytes +max-postcopy-bandwidth: 0 +tls-authz: '' +(qemu) migrate -d tcp:localhost:4444 +(qemu) qemu-system-x86_64: failed to save SaveStateEntry with id(name): 2(ram): -5 +qemu-system-x86_64: Unable to write to socket: Connection reset by peer +``` + +3.dest(in same server): qemu-system-x86_64 -cpu Cascadelake-Server-v4 -smp 10 -enable-kvm -m 50G -nographic -serial telnet:localhost:4322,server,nowait -nic tap,ifname=tap1,script=no,downscript=no --incoming tcp:0:4444 CentOS-Stream-GenericCloud-9-20230123.0.x86_64_test_0.qcow2 + +``` + QEMU 7.2.91 monitor - type 'help' for more information +(qemu) migrate_set_capability compress on +(qemu) migrate_set_parameter multifd-compression zstd +(qemu) info mi +mice migrate migrate_capabilities +migrate_parameters +(qemu) info migrate_capabilities +xbzrle: off +rdma-pin-all: off +auto-converge: off +zero-blocks: off +compress: on +events: off +postcopy-ram: off +x-colo: off +release-ram: off +block: off +return-path: off +pause-before-switchover: off +multifd: off +dirty-bitmaps: off +postcopy-blocktime: off +late-block-activate: off +x-ignore-shared: off +validate-uuid: off +background-snapshot: off +zero-copy-send: off +postcopy-preempt: off +(qemu) info migr +migrate migrate_capabilities migrate_parameters +(qemu) info migrate_parameters +announce-initial: 50 ms +announce-max: 550 ms +announce-rounds: 5 +announce-step: 100 ms +compress-level: 1 +compress-threads: 8 +compress-wait-thread: on +decompress-threads: 2 +throttle-trigger-threshold: 50 +cpu-throttle-initial: 20 +cpu-throttle-increment: 10 +cpu-throttle-tailslow: off +max-cpu-throttle: 99 +tls-creds: '' +tls-hostname: '' +max-bandwidth: 134217728 bytes/second +downtime-limit: 300 ms +x-checkpoint-delay: 20000 ms +block-incremental: off +multifd-channels: 2 +multifd-compression: zstd +xbzrle-cache-size: 67108864 bytes +max-postcopy-bandwidth: 0 +tls-authz: '' +(qemu) info migrate_capabilitiesqemu-system-x86_64: Unknown combination of migration flags: 0x0 +qemu-system-x86_64: decompress data failed +qemu-system-x86_64: error while loading state section id 2(ram) +qemu-system-x86_64: load of migration failed: Operation not permitted +``` +Additional information: +$ zstd -V +*** zstd command line interface 64-bits v1.5.1, by Yann Collet *** diff --git a/results/classifier/deepseek-2/output/hypervisor/1562653 b/results/classifier/deepseek-2/output/hypervisor/1562653 new file mode 100644 index 000000000..9cb1688ca --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1562653 @@ -0,0 +1,81 @@ + +Ubuntu 15.10: QEMU VM hang if memory >= 1T + +1. Ubuntu 15.10 x86_64 installed on HP SuperDome X with 8CPUs and 4T memory. + +2. Create a VM, install Ubuntu 15.10, if memory >= 1T , VM hang when start. If memory < 1T, it is good. +<domain type='kvm'> + <name>u1510-1</name> + <uuid>39eefe1e-4829-4843-b892-026d143f3ec7</uuid> + <memory unit='KiB'>1073741824</memory> + <currentMemory unit='KiB'>1073741824</currentMemory> + <vcpu placement='static'>16</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> + <boot dev='hd'/> + <boot dev='cdrom'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync'/> + <source file='/vms/images/u1510-1.img'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='0c:da:41:1d:ae:f1'/> + <source bridge='vswitch0'/> + <model type='virtio'/> + <driver name='vhost'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </memballoon> + </devices> +</domain> + +3. The panic stack is + ... cannot show + async_page_fault+0x28 + ioread32_rep+0x38 + ata_sff_data_xfer32+0x8a + ata_pio_sector+0x93 + ata_pio_sectors+0x34 + ata_sff_hsm_move+0x226 + RIP: kthread_data+0x10 + CR2: FFFFFFFF_FFFFFFD8 + +4. Change the host os to Redhat 7.2 , the vm is good even memory >=3.8T. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1565 b/results/classifier/deepseek-2/output/hypervisor/1565 new file mode 100644 index 000000000..71d7aa9c8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1565 @@ -0,0 +1,35 @@ + +s390x TCG migration failure +Description of problem: +We're seeing failures running s390x migration kvm-unit-tests tests with TCG. + +Some initial findings: + +What seems to be happening is that after migration a control block header accessed by the test code is all zeros which causes an unexpected exception. + +I did a bisection which points to c8df4a7aef ("migration: Split save_live_pending() into state_pending_*") as the culprit. +The migration issue persists after applying the fix e264705012 ("migration: I messed state_pending_exact/estimate") on top of c8df4a7aef. + +Applying + +``` +diff --git a/migration/ram.c b/migration/ram.c +index 56ff9cd29d..2dc546cf28 100644 +--- a/migration/ram.c ++++ b/migration/ram.c +@@ -3437,7 +3437,7 @@ static void ram_state_pending_exact(void *opaque, uint64_t max_size, + + uint64_t remaining_size = rs->migration_dirty_pages * TARGET_PAGE_SIZE; + +- if (!migration_in_postcopy()) { ++ if (!migration_in_postcopy() && remaining_size < max_size) { + qemu_mutex_lock_iothread(); + WITH_RCU_READ_LOCK_GUARD() { + migration_bitmap_sync_precopy(rs); +``` +on top fixes or hides the issue. (The comparison was removed by c8df4a7aef.) + +I arrived at this by experimentation, I haven't looked into why this makes a difference. +Steps to reproduce: +1. Run ACCEL=tcg ./run_tests.sh migration-skey-sequential with current QEMU master +2. Repeat until the test fails (doesn't happen every time, but still easy to reproduce) diff --git a/results/classifier/deepseek-2/output/hypervisor/1569053 b/results/classifier/deepseek-2/output/hypervisor/1569053 new file mode 100644 index 000000000..5f81fd41a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1569053 @@ -0,0 +1,39 @@ + +Qemu crashes when I start a second VM from command line + +I am using Qemu on 64 bit x86 platform, operating system ubuntu 14.04. I cloned the latest version of qemu from github and installed on my system. + +I booted the 1st VM with the instruction: + +sudo qemu-system-x86_64 -m 1024 -smp 4 -cpu host -hda /var/lib/libvirt/images/vm1p4.img -boot c -enable-kvm -no-reboot -net none -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/vhost-user1 -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1 -object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc + +It is was launched successfully. +Then I lanched the second VM with the instruction: + +sudo qemu-system-x86_64 -m 1024 -smp 4 -cpu host -hda /var/lib/libvirt/images/vm1p4-2.img -boot c -enable-kvm -no-reboot -net none -chardev socket,id=char2,path=/usr/local/var/run/openvswitch/vhost-user2 -netdev type=vhost-user,id=mynet2,chardev=char2,vhostforce -device virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet2 -object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc + +Qemu crashed right away. Plea see the log below. + + + +sudo qemu-system-x86_64 -m 1024 -smp 4 -cpu host -hda /var/lib/libvirt/images/vm1p4-2.img -boot c -enable-kvm -no-reboot -net none -chardev socket,id=char2,path=/usr/local/var/run/openvswitch/vhost-user2 -netdev type=vhost-user,id=mynet2,chardev=char2,vhostforce -device virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet2 -object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc +KVM internal error. Suberror: 1 +emulation failure +EAX=000cc765 EBX=00000007 ECX=000cc6ac EDX=0000df00 +ESI=1ff00000 EDI=0000d5d7 EBP=ffffffff ESP=0000f9ce +EIP=d5d70000 EFL=00010012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =df00 000df000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =df00 000df000 ffffffff 00809300 +DS =df00 000df000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 00000000 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1571 b/results/classifier/deepseek-2/output/hypervisor/1571 new file mode 100644 index 000000000..edffa5c35 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1575607 b/results/classifier/deepseek-2/output/hypervisor/1575607 new file mode 100644 index 000000000..a9e097645 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1575607 @@ -0,0 +1,52 @@ + + vm startup failed, qemu returned "kvm run failed Bad address" + + create a virtual machine and start by libvirt. vm startup failed, qemu returned "kvm run failed Bad address" + the error log is : + +error: kvm run failed Bad address + +EAX=7ffc0000 EBX=7ffbffd0 ECX=fffffff0 EDX=0000002c + +ESI=00006f5c EDI=7ffbffd0 EBP=7ffc0000 ESP=00006f34 + +EIP=000dec7b EFL=00010046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 + +ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] + +SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT + +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy + +GDT= 000f6a80 00000037 + +IDT= 000f6abe 00000000 + +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 + +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 + +DR6=00000000ffff0ff0 DR7=0000000000000400 + +EFER=0000000000000000 + +Code=c3 29 d3 21 cb 39 c3 77 27 3b 5e 0c 72 22 85 ff 75 02 89 df <89> 5f 08 01 da 89 57 0c 89 47 10 89 5e 10 8b 56 04 89 f8 e8 8c fc ff ff 89 d8 eb 06 8b 36 + + we add numa in the vm, the numatune info is: + <numatune> + + <memory mode='strict' placement='auto'/> + + </numatune> + + the version of qemu is 2.5.0. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1580 b/results/classifier/deepseek-2/output/hypervisor/1580 new file mode 100644 index 000000000..db7a1ff24 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1580 @@ -0,0 +1,45 @@ + +QEMU crashes when running inside Hyper-V VM on AMD EPYC +Description of problem: +Starting the VM very rarely succeeds and often it crashes with: +``` +# qemu-system-x86_64 -cpu EPYC -machine accel=kvm -smp 1 -m 512 -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=OVMF_VARS.fd -drive file=debian-11-nocloud-amd64-20230124-1270.qcow2,format=qcow2 -snapshot -monitor none +qemu: module ui-ui-gtk not found, do you want to install qemu-system-gui package? +qemu: module ui-ui-sdl not found, do you want to install qemu-system-gui package? +VNC server running on ::1:5900 +KVM internal error. Suberror: 1 +extra data[0]: 0x0000000000000001 +extra data[1]: 0x96d0cff2bed0cf0f +extra data[2]: 0x0bfd29af72b35c7c +extra data[3]: 0x0000000000000400 +extra data[4]: 0x0000000100000004 +extra data[5]: 0x00000000581c356c +extra data[6]: 0x0000000000000000 +extra data[7]: 0x0000000000000000 +emulation failure +EAX=fffd26a4 EBX=00000000 ECX=00000000 EDX=b731cdad +ESI=00000101 EDI=00005042 EBP=fffcc000 ESP=581c3564 +EIP=fffff8a8 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0010 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] +SS =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0008 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= fffffee0 00000027 +IDT= 00000000 00000000 +CR0=40000033 CR2=00000000 CR3=00800000 CR4=00000660 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000100 +Code=00 0f 20 e0 0f ba e8 05 0f 22 e0 31 db e9 13 02 00 00 85 c0 <75> 38 b9 80 00 00 c0 0f 32 0f ba e8 08 0f 30 31 db b9 01 00 00 00 0f a3 0d 04 b0 80 00 74 +``` +Steps to reproduce: +1. Create a [Standard_D8ads_v5 VM](https://learn.microsoft.com/en-us/azure/virtual-machines/dasv5-dadsv5-series) (AMD EPYC 7763 64-Core Processor) in Azure with Debian 11 +2. Install `qemu-system-x86` (1:7.2+dfsg-5~bpo11+1) from `bullseye-backports` +3. Install `ovmf` (2022.11-6) from `bookworm` (testing) +4. Run the commands under "QEMU command line" +Additional information: +VNC displays "Guest has not initialized the display (yet)". The setup works perfectly on a [Standard_D8ds_v5 VM](https://learn.microsoft.com/en-us/azure/virtual-machines/ddv5-ddsv5-series) (Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz). diff --git a/results/classifier/deepseek-2/output/hypervisor/1587 b/results/classifier/deepseek-2/output/hypervisor/1587 new file mode 100644 index 000000000..7f87ba466 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1589153 b/results/classifier/deepseek-2/output/hypervisor/1589153 new file mode 100644 index 000000000..3290ac55a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1589153 @@ -0,0 +1,35 @@ + +qemu-system-x86_64 version 2.5.0 freezes during windows 7 installation in lubuntu 16.04 + +Hi! + +I have been using qemu - kvm for several years in different versions of ubuntu (lubuntu). I am trying to migrate from 15.04 to 16.04 and am having a problem. In particular, on my machine (a samsung series 9 with dual core i7 processor and 8gb ram) the following commands worked in 15.04 but do not work in 15.10 and 16.04. FYI, I tested them on a clean machine, where I have created a 60GB image file in its own partition.. In particular, I am using the command to start installing windows 7 and it works in a clean install of 15.04 (yesterday) but not in 15.10 (yesterday) or 16.04 (the day before). I do not get any error messages in my xterminal when running this and do not know how to check for windows error messages. By not working I mean that after loading files it gets to a windows screen and then stays there forever. + +The command lines used to invoke qemu is: +echo "*** Installing windows 7 virtual machine - Step 2" + + +echo "*** Try command for slow mouse" +export SDL_VIDEO_X11_DGAMOUSE=0 + +sudo qemu-system-x86_64 \ + -enable-kvm \ + -machine pc,accel=kvm \ + -cdrom /home/Archives/Software/OperatingSystems.Windows7HP.64/Windows7HP64_Install.iso \ + -boot d \ + -net nic,macaddr=56:44:45:30:31:34 \ + -net user \ + -cpu host \ + -vga qxl \ + -spice port=5900,disable-ticketing \ + -uuid 8373c3d6-1e6c-f022-38e2-b94e6e14e170 \ + -smp cpus=2,maxcpus=3 \ + -m 6144 \ + -name DrPhilSS9AWin7VM \ + -hda /mnt/Windows7Image/Windows7Guest.img \ + -localtime \ + -k en-us \ + -usb \ + -usbdevice tablet& +sleep 10 +spicy --host 127.0.0.1 --port 5900 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1593756 b/results/classifier/deepseek-2/output/hypervisor/1593756 new file mode 100644 index 000000000..d3299e980 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1593756 @@ -0,0 +1,18 @@ + +qemu-ga won't start on Windows 8.1 guest + +System: Arch Linux, kernel 4.6.2 +VM created with virt-manager 1.3.2 +qemu version 2.6.0 +Windows guest: 8.1, with latest updates (as of now) +Drivers installed from virtio-win iso image (arch package version 0.1.118.2-1) + in particular: vioserial driver version 62.73.104.11800 + +I can start the Guest Agent VSS Provider manually, but the Guest Agent itself doesn't come up. When launched from Console, I get the following: + +<timestamp>: critical: error opening path +<timestamp>: critical: error opening channel +<timestamp>: critical: failed to create guest agent channel +<timestamp>: critical: failed to initialize guest agent channel + +(As possible side effects I have experienced that suspend / resume of the VM only works when I resume, suspend again and resume again. After first resume the VM's screen is frozen and doesn't accept any input. After second resume, all seems to be well.) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1594 b/results/classifier/deepseek-2/output/hypervisor/1594 new file mode 100644 index 000000000..da7468fa5 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1595 b/results/classifier/deepseek-2/output/hypervisor/1595 new file mode 100644 index 000000000..3f72230ee --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1595 @@ -0,0 +1,30 @@ + +CPU boot sometimes fails on big.LITTLE CPUs with varying cache sizes +Description of problem: +The RK3588 SoC has three core clusters; one with A55 cores, and the other two have A76 cores. The big cores have more L2 cache than the little cores, so the value of `CCSIDR` depends on the core that it is read from. + +In `write_list_to_kvmstate`, QEMU attempts to use `KVM_SET_ONE_REG` with an ID for `KVM_REG_ARM_DEMUX_ID_CCSIDR`, trying to set `CCSIDR` to a previously read value. + +Normally, that works fine, but if the host kernel has moved QEMU from one core cluster to the other, then the value will be different and `demux_c15_set` will return `EINVAL`, causing the entire `arm_set_cpu_on` to fail, and the guest kernel to print an error. + +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/sys_regs.c?h=v6.2#n2827 + +I tried changing the condition for the `ok = false` line in `write_list_to_kvmstate` to `ret && r.id >> 8 != 0x60200000001100`. This causes all CPUs to initialize correctly in the guest, but obviously that's a hack. + +I assume that `CCSIDR` not being uniform across all CPUs means that the guest's copy of `CCSIDR` may be wrong, and so cache maintenance operations may not act on the entire cache. I do not know whether that could actually cause problems. Will QEMU need to find the maximum cache size across all CPUs and present that to guests? +Steps to reproduce: +On a SoC where big and little cores have different cache sizes (e.g. RK3588): + +```text +$ qemu-system-aarch64 -M virt -accel kvm -cpu host -smp 4 -nographic -kernel arch/arm64/boot/Image -append quiet +[ 0.001399][ T1] psci: failed to boot CPU1 (-22) +[ 0.001407][ T1] CPU1: failed to boot: -22 +[ 0.001685][ T1] psci: failed to boot CPU2 (-22) +[ 0.001691][ T1] CPU2: failed to boot: -22 +[ 0.001809][ T1] psci: failed to boot CPU3 (-22) +[ 0.001814][ T1] CPU3: failed to boot: -22 +``` + +The error is not always printed, because it depends on which core cluster the processes are scheduled on. + +Using `taskset -c 0-3` or `taskset -c 4-7` to force QEMU to stick to the little or big cores respectively makes the bug not reproduce. diff --git a/results/classifier/deepseek-2/output/hypervisor/1596160 b/results/classifier/deepseek-2/output/hypervisor/1596160 new file mode 100644 index 000000000..a33a3e861 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1596160 @@ -0,0 +1,36 @@ + +SIGSEGV in memory_region_access_valid on Sabre Lite board + +I'm trying to emulate a Sabre Lite board and booting U-Boot, but I'm encountering a SIGSEGV almost immediately after starting QEMU. + +QEMU version: 6f1d2d1c5ad20d464705b17318cb7ca495f8078a +U-Boot version: mx6qsabrelite_defconfig 2016.05 (with http://git.denx.de/?p=u-boot.git;a=commitdiff;h=1f516faa45611aedc8c2e3f303b3866f615d481e reverted, since it hangs the CPU) + +$ gdb --args ./arm-softmmu/qemu-system-arm -machine sabrelite -kernel ~/u-boot-2016.05/u-boot +GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 + +... + +(gdb) r +Starting program: /home/kota/qemu/build/arm-softmmu/qemu-system-arm -machine sabrelite -kernel /home/kota/u-boot-2016.05/u-boot +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fffe9074700 (LWP 18025)] +[New Thread 0x7fffe58c0700 (LWP 18027)] + +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7fffe58c0700 (LWP 18027)] +0x00005555557aaaa8 in memory_region_access_valid (mr=mr@entry=0x7fffe594e0e0, addr=addr@entry=0, size=size@entry=4, is_write=is_write@entry=true) at /home/kota/qemu/memory.c:1143 +1143 if (!mr->ops->valid.unaligned && (addr & (size - 1))) { +(gdb) bt +#0 0x00005555557aaaa8 in memory_region_access_valid (mr=mr@entry=0x7fffe594e0e0, addr=addr@entry=0, size=size@entry=4, is_write=is_write@entry=true) at /home/kota/qemu/memory.c:1143 +#1 0x00005555557aacbd in memory_region_dispatch_write (mr=0x7fffe594e0e0, addr=0, data=3925868734, size=4, attrs=...) at /home/kota/qemu/memory.c:1249 +#2 0x00007fffe645a4e4 in code_gen_buffer () +#3 0x0000555555778d4d in cpu_tb_exec (itb=<optimized out>, itb=<optimized out>, cpu=0x7fffe58c92e0) at /home/kota/qemu/cpu-exec.c:166 +#4 cpu_loop_exec_tb (sc=0x7fffe58bfab0, tb_exit=<synthetic pointer>, last_tb=0x7fffe58bfaa0, tb=<optimized out>, cpu=0x7fffe58c92e0) at /home/kota/qemu/cpu-exec.c:530 +#5 cpu_arm_exec (cpu=cpu@entry=0x7fffe58c1080) at /home/kota/qemu/cpu-exec.c:626 +#6 0x0000555555798a20 in tcg_cpu_exec (cpu=0x7fffe58c1080) at /home/kota/qemu/cpus.c:1541 +#7 tcg_exec_all () at /home/kota/qemu/cpus.c:1574 +#8 qemu_tcg_cpu_thread_fn (arg=<optimized out>) at /home/kota/qemu/cpus.c:1171 +#9 0x00007ffff27f1184 in start_thread (arg=0x7fffe58c0700) at pthread_create.c:312 +#10 0x00007ffff251e37d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1603 b/results/classifier/deepseek-2/output/hypervisor/1603 new file mode 100644 index 000000000..c138fb8a6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1603970 b/results/classifier/deepseek-2/output/hypervisor/1603970 new file mode 100644 index 000000000..1671c4027 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1603970 @@ -0,0 +1,31 @@ + +KVM freezes after live migration (AMD 4184 -> 4234) + +Hi, + +i have two host systems with different CPU types: + +Host A: +AMD Opteron(tm) Processor 4234 + +Host B: +AMD Opteron(tm) Processor 4184 + +Live migration from B -> A works as expected, migration from A -> B always ends in a freezed KVM. If the KVM is frozen, VNC output is still present, however, you can't type anything. CPU usage is always at 100% for one core (so if i set two cores, one is at 100% the other one at 0% usage). + +My command to launch the KVM is the following: + +/usr/bin/kvm -id 104 -chardev socket,id=qmp,path=/var/run/qemu-server/104.qmp,server,nowait -mon chardev=qmp,mode=control -pidfile /var/run/qemu-server/104.pid -daemonize -smbios type=1,uuid=26dd83a9-b9bd-4641-8016-c55f255f1bdf -name kilian-test -smp 1,sockets=1,cores=1,maxcpus=1 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000 -vga cirrus -vnc unix:/var/run/qemu-server/104.vnc,x509,password -cpu kvm64,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 512 -object memory-backend-ram,id=ram-node0,size=512M -numa node,nodeid=0,cpus=0,memdev=ram-node0 -k de -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=tablet,bus=uhci.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-name=iqn.1993-08.org.debian:01:5ca1e9d334b2 -drive file=/mnt/pve/nfs_synology/images/104/vm-104-disk-2.qcow2,if=none,id=drive-virtio0,format=qcow2,cache=none,aio=native,detect-zeroes=on -device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 -netdev type=tap,id=net0,ifname=tap104i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=66:33:31:36:35:36,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 + + +KVM / QEMU version: QEMU emulator version 2.5.1.1 + +I have tried to set different CPU types, but no one works (qemu64, vm64, Opteron_G1, ...). + + +I have found an email from 2014 where another user reports exactly the same problem: + +http://lists.gnu.org/archive/html/qemu-discuss/2014-02/msg00002.html + +Greets +Kilian \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1608 b/results/classifier/deepseek-2/output/hypervisor/1608 new file mode 100644 index 000000000..bafe7a9f5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1608 @@ -0,0 +1,2 @@ + +QEMU gives wrong MPIDR value for Arm CPU types with MT=1 diff --git a/results/classifier/deepseek-2/output/hypervisor/1609 b/results/classifier/deepseek-2/output/hypervisor/1609 new file mode 100644 index 000000000..695a9022e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1609 @@ -0,0 +1,20 @@ + +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Description of problem: +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Steps to reproduce: +As a user (not root!): +1. as -Q n -K PIC -b -L mandelbrot.s +2. ld -m a.out -o test +3. gdb ./test +4. run + +`as' is from gnu binutils (binutils-2.20.1-sol26-sparc-local.gz). +Additional information: +[mandelbrot.s](/uploads/edfe6f1fd01fa39ecce9ba4201454ae3/mandelbrot.s) + +screenshot: https://imgur.com/a/JD51DJA + +It could very well be a bug in my assembly code, but it is still strange that it crashes the whole system. + +~"kind::Bug"[in_asm.dat.xz](/uploads/6bb43ce2b7d6973da4751d236fb44e12/in_asm.dat.xz) diff --git a/results/classifier/deepseek-2/output/hypervisor/1609968 b/results/classifier/deepseek-2/output/hypervisor/1609968 new file mode 100644 index 000000000..bac735da3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1609968 @@ -0,0 +1,32 @@ + +"cannot set up guest memory" b/c no automatic clearing of Linux' cache + +Version: qemu-2.6.0-1 +Kernel: 4.4.13-1-MANJARO +Full script (shouldn't matter though): https://pastebin.com/Hp24PWNE + +Problem: +When host has been up and used for a while cache has been filled as much that guest can't be started without droping caches. + +Expected behavior: +Qemu should be able to request as much Memory as it needs and cause Linux to drop cache pages if needed. A user shouldn't be required to have to come to this conclusion and having to drop caches to start Qemu with the required amount of memory. + +My fix: +Following command (as root) required before qemu start: +# sync && echo 3 > /proc/sys/vm/drop_caches + +Example: +$ sudo qemu.sh -m 10240 && echo success || echo failed +qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory +failed +$ free + total used free shared buff/cache available +Mem: 16379476 9126884 3462688 148480 3789904 5123572 +Swap: 0 0 0 +$ sudo sh -c 'sync && echo 3 > /proc/sys/vm/drop_caches' +$ free + total used free shared buff/cache available +Mem: 16379476 1694528 14106552 149772 578396 14256428 +Swap: 0 0 0 +$ sudo qemu.sh -m 10240 && echo success || echo failed +success \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1615 b/results/classifier/deepseek-2/output/hypervisor/1615 new file mode 100644 index 000000000..e22c51ac9 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1615 @@ -0,0 +1,12 @@ + +8.0.0: Crash when attempting to commit snapshot +Description of problem: +When trying to commit a snapshot to the backing store, qemu exits with the error: + +`qemu: qemu_mutex_unlock_impl: Operation not permitted` +Steps to reproduce: +1. Run qemu command above +2. Open the monitor virtual console (Ctrl-Alt-2) +3. Execute command: `commit os` +Additional information: +Attached are the [backtrace](/uploads/ba8f519e6b00eb054ba416054c782122/8.0.0-1-bt) and the [configure output](/uploads/17124b45e12b252bd01cf41e7a3d2ea4/8.0.0-1-conf.gz). This is a regression from 7.2.1 diff --git a/results/classifier/deepseek-2/output/hypervisor/1616706 b/results/classifier/deepseek-2/output/hypervisor/1616706 new file mode 100644 index 000000000..48096a3fc --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1616706 @@ -0,0 +1,17 @@ + +watchdog doesn't bring down the VM + +Qemu-kvm version : QEMU emulator version 1.5.3 (qemu-kvm-1.5.3-105.el7), Copyright (c) 2003-2008 Fabrice Billard + +Qemu version: Virsh command line tool of libvirt 1.2.17 + +I have the VM stuck in bios (efi shell), but i don't see the watchdog in the host bringing it down? + +Couple of questions: + +1. Does the watchdog functionality requires the driver in adminvm to trigger the reload? or qemu detects it in the host and causes the reload. + +2. Does this work reliably? I have seen cases where in i have the watchdog daemon in the VM shut, still don't see the VM going down (I put the action in the XML file as power off) + +Thanks +Amit \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1617 b/results/classifier/deepseek-2/output/hypervisor/1617 new file mode 100644 index 000000000..13c0e4ac7 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1617114 b/results/classifier/deepseek-2/output/hypervisor/1617114 new file mode 100644 index 000000000..14532b6ee --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1617114 @@ -0,0 +1,20 @@ + +Qemu 2.6.0 freezes with windows guests + +When launching qemu with the same command line as before 2.6.0, with SDL display, with virtio, for a win-10 guest: + +qemu-system-x86_64 -enable-kvm -name win-10 -machine type=pc,accel=kvm -cpu host -smp cores=1,threads=2,sockets=1 -m 2.7G -balloon virtio -drive file=/home/<username>/.qemu/imgs/win10-coe.qcow2,index=0,media=disk,if=virtio -drive file=/usr/share/virtio/virtio-win.iso,index=1,media=cdrom -drive file=/usr/share/spice-guest-tools/spice-guest-tools.iso,index=2,media=cdrom -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no,vhost=on -usbdevice tablet -usb -display sdl -vga qxl -soundhw ac97 -rtc base=localtime -usbdevice host:0b0e:0032 -usbdevice host:0b0e:0348 -usbdevice host:0b0e:0410 + +Qemu at some point just freezes with no error message at all with newer version 2.6.0-1. + +Reverting to prior version 2.5.1-1, things go back to normal. + +A simple way to accelerate the freeze is to have qemu launch in a workspace/desktop, and then move to a different workspace/desktop, and then move back to the qemu workspace/desktop, and you'll find out it's frozen. + +BTW, there's no way to get into qemu monitor mode terminal at all once frozen. The monitor terminal shows up, but does nothing... + +Perhaps it's useful to notice that I have up to date win-10 virtio drivers for ethernet, scsi/storage, qxl-dod, balloon, and serial interface drivers. The ISO version used is 0.1.118.1 (virtio-win AUR package). + +Using the standard (std) qemu video driver, rather than the qxl-dod one makes no difference BTW. + +Just in case, running on up to date x86-64 Arch, plain qemu command line. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1619 b/results/classifier/deepseek-2/output/hypervisor/1619 new file mode 100644 index 000000000..c6ec1ef4c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1619 @@ -0,0 +1,2 @@ + +Emulate x86_64 on ARM machine diff --git a/results/classifier/deepseek-2/output/hypervisor/1624896 b/results/classifier/deepseek-2/output/hypervisor/1624896 new file mode 100644 index 000000000..bc465a879 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1624896 @@ -0,0 +1,24 @@ + +[PPC] SegFault due to Stack Overflow in E500 + + +I am getting a Segmentation Fault while simulating a PowerPC e500. I've tried to debug the problem and I've found that it occurs when you have a 0 value decrementer. The function trace is the following: + +1) __cpu_ppc_store_decr (ppc.c) is called with value = 0 and raise_excp=booke_decr_cb; +2) Since value < 3, booke_decr_cb is called; +3) booke_decr_cb then calls booke_update_irq() and cpu_ppc_store_decr(); +4) cpu_ppc_store_decr calls __cpu_ppc_store_decr + +You're stuck on this infinite cycle until your stack overflows eventually. + +Command Line: +qemu-system-ppc -cpu e500v2 -d guest_errors,unimp -m 2048 -M ppce500 -nographic -bios ../cc/share/qem +u/u-boot.e500 -kernel XKYAPP.exe + +Platform where the bug occured: Bash ubuntu on Windows; + +Revision where the bug was found: e3571ae30cd26d19efd4554c25e32ef64d6a36b3 (16 Set 2016) + + + +Thanks! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1633508 b/results/classifier/deepseek-2/output/hypervisor/1633508 new file mode 100644 index 000000000..99910b670 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1633508 @@ -0,0 +1,34 @@ + +libvirt cannot hot insert interfaces to qemu + +When attempting to hot insert an interface using Ubuntu 16.04.1, I get the following +$ virsh attach-interface --domain gluster1 --type direct \ +> --source test0 --model virtio \ +> --mac 2a:b6:b0:dc:c7:c4 --config --live +error: Failed to attach interface +error: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS + +test0 exists: +$ ip link show test0 +35: test0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 + link/ether aa:8c:65:2e:79:61 brd ff:ff:ff:ff:ff:ff + +Just in case I did it wrong with direct, I did network +$ virsh net-list + Name State Autostart Persistent +---------------------------------------------------------- + default active yes yes + mgmtnet0 active yes yes + +$ virsh attach-interface --domain gluster1 --type network \ +> --source default --model virtio \ +> --mac 2a:b6:b0:dc:c7:c4 --config --live +error: Failed to attach interface +error: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS + + +This seems to be an old bug, but is still present. Other relevant information: +$ qemu-system-x86_64 --version +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.5), Copyright (c) 2003-2008 Fabrice Bellard +$ virsh -v +1.3.1 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1634852 b/results/classifier/deepseek-2/output/hypervisor/1634852 new file mode 100644 index 000000000..50222eba7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1634852 @@ -0,0 +1,47 @@ + +Qemu VirtFS mounts are not accessible after resuming guest from hibernation + +Host OS: Funtoo Linux +Host Kernel: 4.7.4-gentoo +Qemu Version: 2.7.0 +Guest OS: Ubuntu 14.04 +Guest Kernel: reproduced with both 4.4.0-42-generic and 3.13.0-98-generic + +Qemu command line: + +qemu-system-x86_64 \ + -machine type=pc,accel=kvm \ + -cpu host \ + -smp 3 \ + -m 8G \ + -netdev bridge,id=hn0,vhost=on \ + -device virtio-net-pci,netdev=hn0,mac=52:54:fa:70:35:f7 \ + -drive file=/dev/mapper/vg-ubuntu,format=raw,if=virtio,cache=none,discard=on \ + -virtfs local,path=/home/dharding/code,security_model=passthrough,mount_tag=code \ + -virtfs local,path=/home/dharding/xfer,security_model=passthrough,mount_tag=xfer \ + -display gtk + + +Relevant lines from guest /etc/fstab: +code /home/dharding/code 9p trans=virtio,version=9p2000.L,msize=262144,_netdev 0 0 +xfer /home/dharding/xfer 9p trans=virtio,version=9p2000.L,msize=262144,_netdev 0 0 + + +Steps to reproduce: +- start qemu using the above command line +- in the guest, run "sudo pm-hibernate" +- after qemu exits, run again using the same command line +- once the guest resumes from hibernation, run "ls /home/dharding/code" +- the ls command will hang forever + +The ls call stack is: + +[<ffffffffc00743a0>] p9_client_rpc+0x110/0x460 [9pnet] +[<ffffffffc0076a50>] p9_client_getattr_dotl+0x60/0x160 [9pnet] +[<ffffffffc009ef77>] v9fs_vfs_getattr_dotl+0x47/0xa0 [9p] +[<ffffffff81202a5c>] vfs_getattr_nosec+0x2c/0x40 +[<ffffffff81202b26>] vfs_getattr+0x26/0x30 +[<ffffffff81202bf5>] vfs_fstatat+0x65/0xa0 +[<ffffffff8120306f>] SYSC_newstat+0x1f/0x40 +[<ffffffff812032be>] SyS_newstat+0xe/0x10 +[<ffffffff817fa4f6>] entry_SYSCALL_64_fastpath+0x16/0x75 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1635 b/results/classifier/deepseek-2/output/hypervisor/1635 new file mode 100644 index 000000000..0a762119f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1635 @@ -0,0 +1,38 @@ + +Slow graphics output under aarch64 hvf (no dirty bitmap tracking) +Description of problem: +When using a display adapter such as `bochs-display` (which, yes, I realize is not the ideal choice for an aarch64 guest, but it works fine under TCG and KVM, so bear with me) under `hvf` acceleration on an M1 Mac, display output is slow enough to be measured in seconds-per-frame. + +The issue seems to stem from each write to the framebuffer memory resulting in a data abort, while the expected behavior is that only one such write results in a data abort exception, which is handled by marking the region dirty and then subsequent writes do not yield exceptions until the display management in QEMU resets the dirty flag. Instead, every pixel drawn causes the VM to trap, and performance is degraded. +Steps to reproduce: +1. Start an aarch64 HVF guest with the `bochs-display` display adapter. +2. Observe performance characteristics. +3. +Additional information: +I reported this issue on IRC around a year ago, and was provided with a patch by @agraf which I have confirmed works. That patch was shared on the `qemu-devel` mailing list in February, 2022, with a response from @pm215: https://lists.gnu.org/archive/html/qemu-devel/2022-02/msg00609.html + +As a quick summary, the patch takes this snippet from the i386 HVF target: + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/hvf/hvf.c#L132-138 + +And applies a variation of it to the ARM target when handling a data abort exception, before this assert: + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/hvf/hvf.c#L1381 + +Something to the effect of: + +```c + if (iswrite) { + uint64_t gpa = hvf_exit->exception.physical_address; + hvf_slot *slot = hvf_find_overlap_slot(gpa, 1); + + if (slot && slot->flags & HVF_SLOT_LOG) { + memory_region_set_dirty(slot->region, 0, slot->size); + hv_vm_protect(slot->start, slot->size, HV_MEMORY_READ | + HV_MEMORY_WRITE | HV_MEMORY_EXEC); + break; + } + } +``` + +I am reporting this issue now as I updated my git checkout with the release of QEMU 8.0.0 and was surprised to find that the patch had never made it upstream and the issue persists. diff --git a/results/classifier/deepseek-2/output/hypervisor/1635695 b/results/classifier/deepseek-2/output/hypervisor/1635695 new file mode 100644 index 000000000..20e2a54d2 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1636217 b/results/classifier/deepseek-2/output/hypervisor/1636217 new file mode 100644 index 000000000..5d81108cd --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1636217 @@ -0,0 +1,51 @@ + +qemu-kvm 2.7 does not boot kvm VMs with virtio on top of VMware ESX + +After todays Proxmox update all my Linux VMs stopped booting. + +# How to reproduce +- Have KVM on top of VMware ESX (I use VMware ESX 6) +- Boot Linux VM with virtio Disk drive. + + +# Result +virtio based VMs do not boot anymore: + +root@demotuxdc:/etc/pve/nodes/demotuxdc/qemu-server# grep virtio0 100.conf +bootdisk: virtio0 +virtio0: pvestorage:100/vm-100-disk-1.raw,discard=on,size=20G + +(initially with cache=writethrough, but that doesn´t matter) + +What happens instead is: + +- BIOS displays "Booting from harddisk..." +- kvm process of VM loops at about 140% of Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz Skylake dual core CPU + +Disk of course has valid bootsector: + +root@demotuxdc:/srv/pvestorage/images/100# file -sk vm-100-disk-1.raw +vm-100-disk-1.raw: DOS/MBR boot sector DOS/MBR boot sector DOS executable (COM), boot code +root@demotuxdc:/srv/pvestorage/images/100# head -c 2048 vm-100-disk-1.raw | hd | grep GRUB +00000170 be 94 7d e8 2e 00 cd 18 eb fe 47 52 55 42 20 00 |..}.......GRUB .| + + +# Workaround 1 +- Change disk from virtio0 to scsi0 +- Debian boots out of the box after this change +- SLES 12 needs a rebuilt initrd +- CentOS 7 too, but it seems that is not even enough and it still fails (even in hostonly="no" mode for dracut) + + +# Workaround 2 +Downgrade pve-qemu-kvm 2.7.0-3 to 2.6.2-2. + + +# Expected results +Disk boots just fine via virtio like it did before. + + +# Downstream bug report +Downstream suggests an issue with upstream qemu-kvm: + +https://bugzilla.proxmox.com/show_bug.cgi?id=1181 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1645287 b/results/classifier/deepseek-2/output/hypervisor/1645287 new file mode 100644 index 000000000..dcd120618 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1645287 @@ -0,0 +1,19 @@ + +Option "split" does not available for kernel_irqchip flag in qemu-system-x86_64 + +On releases prior to Yakkety, the "split" option is not available for kernel_irqchip flag in qemu-system-x86_64. + +Yakkety: +kernel_irqchip=on|off|split controls accelerated irqchip support (default=off) + + +Xenial: +kernel_irqchip=on|off controls accelerated irqchip support + +Trusty: +kernel_irqchip=on|off controls accelerated irqchip support + +Precise: +kernel_irqchip=on|off controls accelerated irqchip support + +It will be great to have this option, as we will need this for some kvm-unit-tests for SRU \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1645355 b/results/classifier/deepseek-2/output/hypervisor/1645355 new file mode 100644 index 000000000..2ec6a43ab --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1645355 @@ -0,0 +1,30 @@ + +x86: singlestepping through SYSCALL instruction causes exception in kernelspace + +Hi, + +The bug was originally reported [1] and [2] here. There is a problem inside QEMU with singlestepping from userspace until SYSCALL instruction is reached. The OS has in FMASK TF bit set, therefore there should be no singlestepping exception when transitioning to kernelmode. But, inside QEMU there is (TF is clear seems FMASK is applied). See below for further details. + +The reproducer is available at [2]. + +Here is the original text with some minor clarifications: + +It seems that there is something wrong with QEMU with respect to handle the singlestepping and AMD64 syscall instruction. + +The AMD "syscall" instruction will clear defined flag in the FMASK MSR. Normally the TF flag is set there, so the first instruction when kernel is entered after syscall won't cause single step exception in the kernel. + +The observed scenario is a unhandled singlestep fault in the kernel or host reboot or QEMU crash. + +The possible way how to reproduce it is to single step through any function (in userspace) which does "syscall" instruction. After syscall is entered QEMU will trigger singlestepping exception in the kernel despite that the TF is set in FMASK MSR. Real HW behaves correctly and does not trigger this exception. + + +What is interesting is that I was not able to trigger it if I just enabled TF and did the syscall instruction, perhaps for this bug is somewhat important to have TF set for previous few instruction. + + +I have stumbled to this problem while working with our custom OS. However after some googling I found out that the NetBSD guys (CCed) are having very similar problem and I asked them to prepare a ISO image where the problem ends with QEMU SIGSEGV or host reboot. + +Thanks +Rudolf + +[1] https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02289.html +[2] http://gnats.netbsd.org/49603 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1647 b/results/classifier/deepseek-2/output/hypervisor/1647 new file mode 100644 index 000000000..cb81e3a54 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1652011 b/results/classifier/deepseek-2/output/hypervisor/1652011 new file mode 100644 index 000000000..733049ad8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1652011 @@ -0,0 +1,37 @@ + +VM shuts down due to error in qemu block.c + +On a Trusty KVM host one of the guest VMs shut down without any user interaction. The system is running: + +$ cat /etc/lsb-release +DISTRIB_ID=Ubuntu +DISTRIB_RELEASE=14.04 +DISTRIB_CODENAME=trusty +DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS" + +$ dpkg -l libvirt0 qemu-kvm qemu-system-common qemu-system-x86 +Desired=Unknown/Install/Remove/Purge/Hold +| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend +|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) +||/ Name Version Architecture Description ++++-============================================================-===================================-===================================-============================================================================================================================== +ii libvirt0 1.2.2-0ubuntu13.1.17 amd64 library for interfacing with different virtualization systems +ii qemu-kvm 2.0.0+dfsg-2ubuntu1.27 amd64 QEMU Full virtualization +ii qemu-system-common 2.0.0+dfsg-2ubuntu1.27 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-x86 2.0.0+dfsg-2ubuntu1.27 amd64 QEMU full system emulation binaries (x86) + +In the VMs log in /var/lib/libvirt/qemu/hostname we see: + +2016-11-17 09:18:42.603+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name hostname,process=qemu:hostname -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 12697 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 51766564-ed8e-41aa-91b5-574220af4ac3 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hostname.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/disk1/hostname,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=/dev/disk2/hostname_mnt_data,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/dev/disk1/hostname_tmp,if=none,id=drive-virtio-disk2,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk2,id=virtio-disk2 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,tx=bh,netdev=hostnet0,id=net0,mac=52:54:00:45:e7:d9,bus=pci.0,addr=0x6 -netdev tap,fd=31,id=hostnet1,vhost=on,vhostfd=32 -device virtio-net-pci,tx=bh,netdev=hostnet1,id=net1,mac=52:54:00:f6:6c:77,bus=pci.0,addr=0x7 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:5 -device VGA,id=video0,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 +char device redirected to /dev/pts/6 (label charserial0) +qemu-system-x86_64: /build/qemu-PVxDqC/qemu-2.0.0+dfsg/block.c:3491: bdrv_error_action: Assertion `error >= 0' failed. +2016-12-22 09:49:49.392+0000: shutting down + +In /var/lib/libvirt/libvirtd.log we see: + +2016-12-22 09:49:49.298+0000: 6946: error : qemuMonitorIO:656 : internal error: End of file from monitor + +We investigated to see if this is a known issue and came across a bug report for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1147398), but nothing references changes upstream that fix this. + +The guest OS is Ubuntu Precise (12.04.5) running kernel linux-image-3.2.0-101-virtual 3.2.0-101.141. There wasn't any significant load (CPU or IO) on the guest at the time that it shut down and there wasn't any appreciable disk IO on the KVM host either. The disks for the guest are on the KVM host box. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1652459 b/results/classifier/deepseek-2/output/hypervisor/1652459 new file mode 100644 index 000000000..e482f67ce --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1652459 @@ -0,0 +1,12 @@ + +kvm rbd driver (and maybe others, i.e. qcow2, qed and so on) does not report DISCARD-ZERO flag + +# lsblk -D +NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO +sda 0 4K 1G 0 +├─sda1 0 4K 1G 0 +├─sda2 1024 4K 1G 0 +└─sda5 0 4K 1G 0 + + +Last column should be `1` at least for "RBD+discard=unmap" since reading from discarded regions in RBD MUST return zeroes. The same with QCOW2, QED and sparse raw images. KVM should copy value of this flag when real raw device (i.e. real SSD) with discard capability is used as virtual disk. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1657010 b/results/classifier/deepseek-2/output/hypervisor/1657010 new file mode 100644 index 000000000..855178880 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1657010 @@ -0,0 +1,12 @@ + +RFE: Please implement -cpu best or a CPU fallback option + +QEMU should implement a -cpu best option or some other way to make this work: + +qemu -M pc,accel=kvm:tcg -cpu best + +qemu -M pc,accel=kvm:tcg -cpu host:qemu64 + +See also: + +https://bugzilla.redhat.com/show_bug.cgi?id=1277744#c6 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1657841 b/results/classifier/deepseek-2/output/hypervisor/1657841 new file mode 100644 index 000000000..3239e30a3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1657841 @@ -0,0 +1,12 @@ + +QEMU Intel HAX Windows + +Hi, + +Using the latest exe's from http://qemu.weilnetz.de/w32/ + +C:\Users\therock247uk\Desktop\jan\qemu-w64-setup-20170113>qemu-system-i386 --enable-hax -m 512 -cdrom C:\Users\therock247uk\Desktop\jan\en_windows_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso +HAX is working and emulator runs in fast virt mode. +Failed to allocate 20000000 memory + +The emulator seems to hang/get stuck during booting from the CD taking out --enable-hax allows it to boot. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1668556 b/results/classifier/deepseek-2/output/hypervisor/1668556 new file mode 100644 index 000000000..bd1f8baf6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1668556 @@ -0,0 +1,20 @@ + +QEMU Guest Agent service fails to start on Windows 10 RS2 preview + +The "QEMU Guest Agent" service cannot be started on Windows 10 RS2 preview build. After starting the service this error message is displayed: "Windows could not start QEMU Guest Agent service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." + +Output from the Windows System event log: +<?xml version="1.0" encoding="utf-8" standalone="yes"?> +<Events><Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Service Control Manager' Guid='{555908d1-a6d7-4695-8e1e-26931d2012f4}' EventSourceName='Service Control Manager'/><EventID Qualifiers='49152'>7009</EventID><Version>0</Version><Level>2</Level><Task>0</Task><Opcode>0</Opcode><Keywords>0x8080000000000000</Keywords><TimeCreated SystemTime='2017-02-28T09:39:35.713939500Z'/><EventRecordID>1406</EventRecordID><Correlation/><Execution ProcessID='568' ThreadID='964'/><Channel>System</Channel><Computer>LT-WIN10-64</Computer><Security/></System><EventData><Data Name='param1'>30000</Data><Data Name='param2'>QEMU Guest Agent</Data><Binary>510045004D0055002D00470041000000</Binary></EventData></Event></Events> + +The "QEMU Guest Agent VSS Provider" service is running successfully. + +It worked on Windows 10 RS1 (before the upgrade). + +QEMU Guest Agent version: +Installed from virtio-win-0.1.126_amd64 +which was built from master branch with latest commit (8aaf403) - https://github.com/virtio-win/kvm-guest-drivers-windows + +Windows version (upgraded from RS1): +Windows 10 Enterprise Insider Preview +Evaluation copy. Build 15019.rs_prerelease.170121-1513 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1669 b/results/classifier/deepseek-2/output/hypervisor/1669 new file mode 100644 index 000000000..35f24937a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1669 @@ -0,0 +1,12 @@ + +In the ARM environment, using pci-ohci with specific OS (CentOS-8-aarch64-1905-dvd1.iso) to start a virtual machine, will cause the memory leak +Description of problem: + +Steps to reproduce: +1.Using the pci-ohci as the USB controller to start the VM; + +2.install the OS using the CentOS-8-aarch64-1905-dvd1.iso ; + +3.The QEMU process is taking up more and more memory, which looks like Memory leak +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1672365 b/results/classifier/deepseek-2/output/hypervisor/1672365 new file mode 100644 index 000000000..b2be9cd00 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1672365 @@ -0,0 +1,47 @@ + +nested 9pfs read fail + +tl;dr: A virtfs read fails. The init being on this virtfs (mounted by the initrd), the linux kernel guest is unable to boot, and kernel panics. The fact that qemu still takes 100%cpu after the kernel panic makes me think it's a qemu bug. + +Here is the setup (some hashes replaced with "..."): + * A (NixOS) host system, with /nix/store as a btrfs on lvm on cryptsetup + * Running a qemu-kvm NixOS guest, with /nix/.ro-store as a virtfs mapping to host /nix/store: +``` +exec /nix/store/...-qemu-x86-only-for-vm-tests-2.8.0/bin/qemu-kvm \ + -name test \ + -m 8192 \ + -cpu kvm64 \ + -net nic,vlan=0,model=virtio -net user,vlan=0 \ + -virtfs local,path=/nix/store,security_model=none,mount_tag=store \ + -virtfs local,path=/tmp/nix-vm..../xchg,security_model=none,mount_tag=xchg \ + -virtfs local,path=/tmp/nix-vm..../xchg,security_model=none,mount_tag=shared \ + -drive index=0,id=drive1,file=/home/ekleog/nixos/test.qcow2,if=virtio,cache=writeback,werror=report \ +-kernel /nix/store/...-nixos-system-test-17.09.git.deee8da/kernel \ +-initrd /nix/store/...-nixos-system-test-17.09.git.deee8da/initrd \ +-append "$(cat /nix/store/...-nixos-system-test-17.09.git.deee8da/kernel-params) init=/nix/store/...-nixos-system-test-17.09.git.deee8da/init regInfo=/nix/store/...-reginfo" \ + -vga std -usbdevice tablet +``` + * With /nix/store as an overlayfs between /nix/.ro-store and /nix/.rw-store + * Running a qemu-kvm NixOS guest, with /nix/.ro-store as a virtfs mapping to host /nix/store/...-vm-nginx-store: +``` +/nix/store/...-qemu-2.8.0/bin/qemu-kvm \ + -name nginx -m 128 -smp 2 -cpu kvm64 \ + -nographic -serial unix:"/var/lib/vm/consoles/nginx/socket.unix",server,nowait \ + -drive file="/var/lib/vm/images/nginx.img",if=virtio,media=disk \ + -virtfs local,path="/nix/store/...-vm-nginx-store",security_model=none,mount_tag=store \ + -netdev type=tap,id=net0,ifname=vm-nginx,script=no,dscript=no -device virtio-net-pci,netdev=net0,mac=56:00:00:00:00:01 \ + -kernel /nix/store/...-nixos-system-nginx-17.09.git.deee8da/kernel \ + -initrd /nix/store/...-nixos-system-nginx-17.09.git.deee8da/initrd \ + -append "$(cat /nix/store/...-nixos-system-nginx-17.09.git.deee8da/kernel-params) init=/nix/store/...-nixos-system-nginx-17.09.git.deee8da/init console=ttyS0 boot.shell_on_fail" \ + -virtfs local,path="/var/lib/vm/persist/nginx/home",security_model=mapped-xattr,mount_tag="shared1" \ + -virtfs local,path="/var/lib",security_model=mapped-xattr,mount_tag="shared2" \ + -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared3" +``` + * With /nix/store as an overlayfs between /nix/.ro-store and /nix/.rw-store + * With init in /nix/store + +What happens is that at boot time the inner VM doesn't manage to read the init script after the initrd has mounted the 9pfs and overlayfs. + +What makes me think it's a qemu bug is that htop in the outer VM shows the inner VM's qemu as using 100% cpu, despite the fact the kernel it's running is under kernel panic, thus doing nothing. + +What do you think about this? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1675 b/results/classifier/deepseek-2/output/hypervisor/1675 new file mode 100644 index 000000000..0d2214c1c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1675 @@ -0,0 +1,2 @@ + +virtual machines still randomly crashing on kernel 6.1.30 diff --git a/results/classifier/deepseek-2/output/hypervisor/1675458 b/results/classifier/deepseek-2/output/hypervisor/1675458 new file mode 100644 index 000000000..207828819 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1675458 @@ -0,0 +1,77 @@ + +attach-interface - unexpected action + +Hello, + +Not sure where to report this, or if it is a bug. However, I feel like the behaviour is not what would/should be expected. + +---------------------------------------------------------------------------------------------------------- + +Environment: +KVM Version: root@hostname:~# virsh version + Compiled against library: libvirt 1.2.9 + Using library: libvirt 1.2.9 + Using API: QEMU 1.2.9 + Running hypervisor: QEMU 2.1.2 +uname -a: Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux +CPU: Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz +Host Debian Version: 8.7 (Jessie) +Guest Debian Version: 8.7 (Jessie) + +---------------------------------------------------------------------------------------------------------- + +Issue: +When adding an interface to a live VM, the position of interfaces within the VM may change post reboot. +It appears a new interface takes up the first available “pci slot”. If you have removed an interface in the past, this will be the one that is taken up. + +---------------------------------------------------------------------------------------------------------- + +Example: + +If the VM Has the following interfaces layout: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 11:11:11:11:11:11 +eth2 HWaddr 22:22:22:22:22:22 +eth3 HWaddr 33:33:33:33:33:33 + +Now I delete the interface with MAC address 11:11:11:11:11:11, you now have this: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 22:22:22:22:22:22 +eth2 HWaddr 33:33:33:33:33:33 + +And then you add a new interface with MAC address 44:44:44:44:44:44, using virsh: + +virsh attach-interface --domain guest --type bridge --source br3 --mac 44:44:44:44:44:44 --model e1000 --target vmeth3 --live --persistent + +It will now look like this: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 22:22:22:22:22:22 +eth2 HWaddr 33:33:33:33:33:33 +eth3 HWaddr 44:44:44:44:44:44 + +However, after a reboot, it will look like this: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 44:44:44:44:44:44 +eth2 HWaddr 22:22:22:22:22:22 +eth3 HWaddr 33:33:33:33:33:33 + +This can be a problem, as /etc/network/interfaces file, etc., will be pointing to the wrong interfaces. I.E. originally eth1 was connected to br1 (for example), after reboot eth1 is now connected to br3. + +To resolve this issue, I need to edit the .xml file in the KVM machine, and edit the following lines: + + <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> + +Changing these into the order I want them to be loaded in, i.e. eth0, eth1, eth2…. (I know 4 are taken already and not usable by ethernet interfaces.) + +---------------------------------------------------------------------------------------------------------- + + +Thanks in advance. + +Kind regards, + +Aaron Doyle \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1677 b/results/classifier/deepseek-2/output/hypervisor/1677 new file mode 100644 index 000000000..2d290dab0 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1679 b/results/classifier/deepseek-2/output/hypervisor/1679 new file mode 100644 index 000000000..35e29dffb --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1679 @@ -0,0 +1,16 @@ + +Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.Enter the issue title +Description of problem: +Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Steps to reproduce: +1.qemu-img.exe create hdd.img 10G + +2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso -machine pc +Additional information: +both Use qemu v8.0 and qemu v8.1 to test, but failed also + + + +Thanks, + +Jianbin diff --git a/results/classifier/deepseek-2/output/hypervisor/1679358 b/results/classifier/deepseek-2/output/hypervisor/1679358 new file mode 100644 index 000000000..7cca475b6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1679358 @@ -0,0 +1,4 @@ + +ARM: RES0/RES1 SCTLR fields not read-only + +There are fields in SCTLR that are RAO/SBOP or WI or in the case of the RR field, accessible only in secure mode. Currently it seems that qemu just propagates any write to SCTLR to the register and this screwed up in a bootloader that I am debugging. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1690322 b/results/classifier/deepseek-2/output/hypervisor/1690322 new file mode 100644 index 000000000..1f5fc1206 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1690322 @@ -0,0 +1,15 @@ + +errors which can't backing storage for guest RAM with -mem-path + +I found it can't backup the guest RAM when i run simple ram test code with + +errors which can't backing storage for guest RAM with integratorcp, the commander is: + +qemu-system-arm -M integratorcp -m 1 -semihosting -nographic -mem-path mem.txt -kernel build/emu_ram_test.elf + +i wrote the patter "0x55" to all of the rest of RAM in my test, after run my test code, it just generate the 1048576 Bytes file, i split these file into 2kB, most of split file is black, some of them just display \00 after open with gedit. + +i don't know whether my commander is incorrect, anyone can confirm it for me? i just want to write the guest RAM and read it from host during the guest code is running. but my guest just has simple os without file system and network. so i want to try with this backend RAM ways. + +thanks. +js \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1691109 b/results/classifier/deepseek-2/output/hypervisor/1691109 new file mode 100644 index 000000000..daccfc394 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1691109 @@ -0,0 +1,14 @@ + +qemu-kvm not working as nested inside ESX 6.0 + +ESX 6.0 (virt bits exposed) - Ubuntu 16.04 + qemu-kvm 1:2.8+dfsg-3ubuntu2~cloud0 - CirrOS launched by OpenStack (devstack master) + + +VM will start with -machine = 'pc-i440fx-zesty' and will stuck in "booting from hard disk" + +to fix it you can manually change -machine to 'pc-i440fx-2.3' + +also, ISOs boots well, so I think it`s something about block devices configuration introduced in new machine type. + +p.s. +also confirmed with RHEL instead of Ubuntu as KVM host - new machine type don`t work \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1694 b/results/classifier/deepseek-2/output/hypervisor/1694 new file mode 100644 index 000000000..ebb6b2aa3 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1694998 b/results/classifier/deepseek-2/output/hypervisor/1694998 new file mode 100644 index 000000000..8b71ac764 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1694998 @@ -0,0 +1,12 @@ + +PPC: msgsnd instruction leads to assertion + +I tried to send doorbells (using msgsnd) between cores in guest OS. On QEMU v2.9.0 usage of msgsnd instruction leads to error: +ERROR: <...>/qemu-new/translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) + + +QEMU v2.8.0 works fine. + +QEMU run options: qemu-system-ppc -serial stdio -M ppce500 -cpu e500mc -smp 2 -m 512M -kernel pok.elf + +pok.elf attached \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1696 b/results/classifier/deepseek-2/output/hypervisor/1696 new file mode 100644 index 000000000..5085e9466 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1696 @@ -0,0 +1,40 @@ + +Linux kernel hangs rarely when booting on the latest qemu +Description of problem: +(Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2213346) + +In Fedora we have noticed that the latest Linux kernel (rarely) hangs when booting +on the latest qemu. It hangs after printing: + +``` +[ 0.070120] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.070120] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.070120] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.070120] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.070120] Spectre V2 : Mitigation: Retpolines +[ 0.070120] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.070120] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT +[ 0.070120] Spectre V2 : Enabling Speculation Barrier for firmware calls +[ 0.070120] RETBleed: Mitigation: untrained return thunk +[ 0.070120] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.070120] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl +[ 0.070120] Freeing SMP alternatives memory: 48K +``` + +The next line which would be printed (if it didn't hang) is: + +``` +[ 0.070794] smpboot: CPU0: AMD Ryzen 9 3900X 12-Core Processor (family: 0x17, model: 0x71, stepping: 0x0) +``` + +We've seen this hang on both AMD and Intel. It probably happens one in every 300 boots. +Steps to reproduce: +By far the easiest way to reproduce this is to just run guestfish in a loop: + +``` +$ while guestfish -a /dev/null -v run >& /tmp/log; do echo -n . ; done +``` +Additional information: +The full qemu command is rather long but you can find it in this log file: + +https://bugzilla-attachments.redhat.com/attachment.cgi?id=1969620 diff --git a/results/classifier/deepseek-2/output/hypervisor/1701449 b/results/classifier/deepseek-2/output/hypervisor/1701449 new file mode 100644 index 000000000..5d9b326bd --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1701449 @@ -0,0 +1,63 @@ + +high memory usage when using rbd with client caching + +Hi, +we are experiencing a quite high memory usage of a single qemu (used with KVM) process when using RBD with client caching as a disk backend. We are testing with 3GB memory qemu virtual machines and 128MB RBD client cache. When running 'fio' in the virtual machine you can see that after some time the machine uses a lot more memory (RSS) on the hypervisor than she should. We have seen values (in real production machines, no artificially fio tests) of 250% memory overhead. I reproduced this with qemu version 2.9 as well. + +Here the contents of our ceph.conf on the hypervisor: +""" +[client] +rbd cache writethrough until flush = False +rbd cache max dirty = 100663296 +rbd cache size = 134217728 +rbd cache target dirty = 50331648 +""" + +How to reproduce: +* create a virtual machine with a RBD backed disk (100GB or so) +* install a linux distribution on it (we are using Ubuntu) +* install fio (apt-get install fio) +* run fio multiple times with (e.g.) the following test file: +""" +# This job file tries to mimic the Intel IOMeter File Server Access Pattern +[global] +description=Emulation of Intel IOmeter File Server Access Pattern +randrepeat=0 +filename=/root/test.dat +# IOMeter defines the server loads as the following: +# iodepth=1 Linear +# iodepth=4 Very Light +# iodepth=8 Light +# iodepth=64 Moderate +# iodepth=256 Heavy +iodepth=8 +size=80g +direct=0 +ioengine=libaio + +[iometer] +stonewall +bs=4M +rw=randrw + +[iometer_just_write] +stonewall +bs=4M +rw=write + +[iometer_just_read] +stonewall +bs=4M +rw=read +""" + +You can measure the virtual machine RSS usage on the hypervisor with: + virsh dommemstat <machine name> | grep rss +or if you are not using libvirt: + grep RSS /proc/<PID of qemu process>/status + +When switching off the RBD client cache, all is ok again, as the process does not use so much memory anymore. + +There is already a ticket on the ceph bug tracker for this ([1]). However I can reproduce that memory behaviour only when using qemu (maybe it is using librbd in a special way?). Running directly 'fio' with the rbd engine does not result in that high memory usage. + +[1] http://tracker.ceph.com/issues/20054 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1702 b/results/classifier/deepseek-2/output/hypervisor/1702 new file mode 100644 index 000000000..8ec0dfd97 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1703506 b/results/classifier/deepseek-2/output/hypervisor/1703506 new file mode 100644 index 000000000..c35aeae0b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1703506 @@ -0,0 +1,10 @@ + +SMT not supported by QEMU on AMD Ryzen CPU + +HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this message when setting the topology to threads=2: + +qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please configure -smp options properly. + +Checking in a Windows 10 guest reveals that SMT is not enabled, and from what I understand, QEMU converts the topology from threads to cores internally on AMD CPUs. This appears to cause performance problems in the guest perhaps because programs are assuming that these threads are actual cores. + +Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro guest \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1706 b/results/classifier/deepseek-2/output/hypervisor/1706 new file mode 100644 index 000000000..a571eb003 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1706 @@ -0,0 +1,10 @@ + +Allow TCG plugins to read registers +Additional information: +- `include/qemu/plugin.h` +- `include/qemu/qemu-plugin.h` + +PANDA implemented this already but it is not a very clean solution: +- https://github.com/panda-re/qemu/commit/b97c5a56edd0ba3b5f6ab16bf531ac1f7abaac04 (mentioned in QPP patch series: https://lore.kernel.org/qemu-devel/20221213213757.4123265-1-fasano@mit.edu/) + +I personally think the flag for the TB translation and execution callbacks makes more sense diff --git a/results/classifier/deepseek-2/output/hypervisor/1708 b/results/classifier/deepseek-2/output/hypervisor/1708 new file mode 100644 index 000000000..24c7c7120 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1708077 b/results/classifier/deepseek-2/output/hypervisor/1708077 new file mode 100644 index 000000000..4ffab34fd --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1708077 @@ -0,0 +1,4 @@ + +PPC interrupt exception！ + +There is a exception on interrupt system when run the system with debug app on qemu-system-ppc.exe。I have try in version SHA-1: 2421f381dc38a8a6d12477c08c2f74a35a0698f8 no problem，but the next version SHA-1: 28f997a82cb509bf4775d4006b368e1bde8b7bdd have this exception。 And I found during this period in the repair of multi-threaded mutex，so I guess whether the PPC has some mutex needed are not taken into account。My english is poor，so there may be many grammatical errors。I hope you can understand the problem I described。 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1709025 b/results/classifier/deepseek-2/output/hypervisor/1709025 new file mode 100644 index 000000000..e08489b5a --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1711 b/results/classifier/deepseek-2/output/hypervisor/1711 new file mode 100644 index 000000000..f765a2f93 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1711 @@ -0,0 +1,2 @@ + +unable to set PWD with guest-exec without starting a shell diff --git a/results/classifier/deepseek-2/output/hypervisor/1712564 b/results/classifier/deepseek-2/output/hypervisor/1712564 new file mode 100644 index 000000000..aa86d8ffb --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1714331 b/results/classifier/deepseek-2/output/hypervisor/1714331 new file mode 100644 index 000000000..4c3f3fe11 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1714331 @@ -0,0 +1,76 @@ + +Virtual machines not working anymore on 2.10 + +Using 2.10, my virtual machine(s) don't work anymore. This happens 100% of the times. + +----- + +I use QEMU compiling it from source, on Ubuntu 16.04 amd64. This is the configure command: + + configure --target-list=x86_64-softmmu --enable-debug --enable-gtk --enable-spice --audio-drv-list=pa + +I have one virtual disk, with a Windows 10 64-bit, which I launch in two different ways; both work perfectly on 2.9 (and used to do on 2.8, but I haven't used it for a long time). + +This is the first way: + + qemu-system-x86_64 + -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp + -enable-kvm + -machine q35,accel=kvm,mem-merge=off + -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + -smp 4,cores=4,sockets=1,threads=1 + -m 4096 + -display gtk + -vga qxl + -rtc base=localtime + -serial none + -parallel none + -usb + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device virtio-scsi-pci,id=scsi + -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback + -device scsi-hd,drive=hdd1 + -net nic,model=virtio + -net user + +On QEMU 2.10, I get the `Recovery - Your PC/Device needs to be repaired` windows screen; on 2.9, it boots regularly. + +This is the second way: + + qemu-system-x86_64 + -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp + -enable-kvm + -machine q35,accel=kvm,mem-merge=off + -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + -smp 4,cores=4,sockets=1,threads=1 + -m 10240 + -vga none + -rtc base=localtime + -serial none + -parallel none + -usb + -device vfio-pci,host=01:00.0,multifunction=on + -device vfio-pci,host=01:00.1 + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device virtio-scsi-pci,id=scsi + -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback + -device scsi-hd,drive=hdd1 + -net nic,model=virtio + -net user + +On QEMU 2.10, I get the debug window on the linux monitor, and blank screen on VFIO one (no BIOS screen at all); after 10/20 seconds, QEMU crashes without any message. +On 2.9, this works perfectly. + +----- + +I am able to perform a git bisect, if that helps, but if this is the case, I'd need this issue to be reviewed, since bisecting is going to take me a lot of time. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1715573 b/results/classifier/deepseek-2/output/hypervisor/1715573 new file mode 100644 index 000000000..a678c9fec --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1715700 b/results/classifier/deepseek-2/output/hypervisor/1715700 new file mode 100644 index 000000000..24c837515 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1715700 @@ -0,0 +1,27 @@ + +Windows 7 guest won't boot on qemu 2.10 (works on 2.9) + +Qemu version: 2.10 stable. +Guest: Windows 7 SP1 x64, virtio drivers are already installed in the guest. +Command line: +qemu-system-x86_64 \ + -nodefaults \ + -nodefconfig \ + -machine type=q35,accel=kvm \ + -enable-kvm \ + -cpu host \ + -m 2048 \ + -vga virtio \ + -boot menu=on \ + -smbios file=/path/dmidecode_BIOS.bin \ + -acpitable file=/path/acpi_slic.bin \ + -bios /path/OVMF_CODE.fd \ + -net none \ + -drive if=virtio,media=disk,file=/media/win7.qcow2 \ + -device pcie-root-port \ + -device ich9-usb-ehci1 \ + -device ich9-usb-uhci1 \ + -device ich9-usb-uhci2 \ + -device ich9-usb-uhci3 + +Windows hangs at boot with waving flag screen (flag doesn't freeze, keeps waving indefinitely). Same command line boots fine with Qemu 2.9. I tried changing machine type to pc-q35-2.9 - same result. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1716 b/results/classifier/deepseek-2/output/hypervisor/1716 new file mode 100644 index 000000000..92be1f5d6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1716 @@ -0,0 +1,10 @@ + +Cannot raise low memory using max-ram-below-4g on current i440fx +Description of problem: +We have a use case where we have a virtual machine with at least 8 Gb of RAM and at least 3.5Gb of it in the low memory. However, I could not achieve it this far with QEMU, only on the deprecated i440fx 1.7 architecture. The size of lowmem is never greater than 3 Gb, except if I assign memory to the vm between 3 Gb and 3.5 Gb. If I go even a slightly above 3.5 Gb then it falls back to 3 Gb. + +I did some research and I found the source file hw/i386/pc_piix.c. There is a piece of code which is responsible for setting the low memory at the beginning of function pc_init1(). It seems that the problem lies in the property `gigabyt_align` of all i440fx architectures newer than 1.7. The comment which explains this piece of code does not mention at all that raising lowmem does not work on newer pc architectures. According to the comments setting the size of lowmem based of the `max-ram-below-4g` option should happen before the gigabyte alignment, not after it. Anyway, it does not make sense because with default being 3 Gb gigabyte alignment always means 3 Gb so raising is not possible at all. The last example of the comment clearly states that raising should be possible using the newest `pc` architecture: `qemu -M pc,max-ram-below-4g=4G -m 3968M -> 3968M low (=4G-128M)`. However, according to the code below the comment this is not the way it works because gigabyte alignment happens after. + +To solve the problem there are two possibilities: if this is a bug then the solution is obvious, the gigabyte aligment should happen before applying the `max-ram-below-4g` option. If this is not a bug but the expected way of working then there could be an option to override the `gigabyte_align` attribute from command line. + +What do you think? diff --git a/results/classifier/deepseek-2/output/hypervisor/1717 b/results/classifier/deepseek-2/output/hypervisor/1717 new file mode 100644 index 000000000..bac1e895c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1717 @@ -0,0 +1,30 @@ + +GPU passthrough (NV h100)case vfio Error +Description of problem: +GPU passthrough (NV h100) will case a error + + +qemu-system-x86_64: vfio_err_notifier_handler(0000:17:00.0) Unrecoverable error detected. Please collect any data possible and then kill the guest + + +this error happen in centos, redhat linux,ubuntu with some kernel i have try( 5.19.0,6.0,6.2) +The same server insert L4,L40 GPU, will not happen. Only happen on H100 GPU +The same server install esxios. everything is normal. GPU work fine + +With vfio error. there is some idrac log error on my dell server + +``` +A bus fatal error was detected on a component at slot 2. Tue Jun 20 2023 05:51:51 +A fatal error was detected on a component at bus 23 device 0 function 0. Tue Jun 20 2023 05:51:51 +A fatal error was detected on a component at bus 22 device 2 function 0. Tue Jun 20 2023 05:51:51 +``` + +Otherwise, I have try to passthrough gpu on dell amd and intel server both. +With AMD CPU , gpu not working in vm. but will not case vfio error +With INTEL CPU, will case vfio error. +Steps to reproduce: +1. Set GPU passthrought +2. Start VM +3. Do something in vm +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1721220 b/results/classifier/deepseek-2/output/hypervisor/1721220 new file mode 100644 index 000000000..9bedba5b7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1721220 @@ -0,0 +1,16 @@ + +qemu crashes with assertion error `!mr->container' failed + +Re-production steps: +git clone today's qemu git tree (4th Oct 2017) +./configure --target-list=ppc64-softmmu && make -j 8 + +Run the device-crash-test from scripts folder, seeing the following error + +INFO: running test case: machine=bamboo binary=ppc64-softmmu/qemu-system-ppc64 device=pcie-pci-bridge accel=kvm +WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine bamboo,accel=kvm -device pcie-pci-bridge +CRITICAL: failed: machine=bamboo binary=ppc64-softmmu/qemu-system-ppc64 device=pcie-pci-bridge accel=kvm +CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine bamboo,accel=kvm -device pcie-pci-bridge +CRITICAL: log: qemu-system-ppc64: /home/nasastry/qemu/memory.c:1699: memory_region_finalize: Assertion `!mr->container' failed. +CRITICAL: log: warning: KVM does not support watchdog +CRITICAL: exit code: -6 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1723488 b/results/classifier/deepseek-2/output/hypervisor/1723488 new file mode 100644 index 000000000..f72ef01fb --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1724570 b/results/classifier/deepseek-2/output/hypervisor/1724570 new file mode 100644 index 000000000..a2da06f45 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1726394 b/results/classifier/deepseek-2/output/hypervisor/1726394 new file mode 100644 index 000000000..3847e6b68 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1726394 @@ -0,0 +1,6 @@ + +Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) + +qemu-user passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) unmodified, but the third argument is an address to a BPF filter, causing an EFAULT. Now, the filter is architecture-specifc, so you can't just rewrite the addresses, so the safest bet is to just return an error here. + +I guess you should just return EINVAL, but not sure. I'd really like something that can be identified, so seccomp errors can be ignored when it's not supported. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1728256 b/results/classifier/deepseek-2/output/hypervisor/1728256 new file mode 100644 index 000000000..16b7d89e6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1728256 @@ -0,0 +1,11 @@ + +Memory corruption in Windows 10 guest / amd64 + +I have a Win 10 Pro x64 guest inside a qemu/kvm running on an Arch x86_64 host. The VM has a physical GPU passed through, as well as the physical USB controllers, as well as a dedicated SSD attached via SATA; you can find the complete libvirt xml here: https://pastebin.com/U1ZAXBNg +I built qemu from source using the qemu-minimal-git AUR package; you can find the build script here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qemu-minimal-git (if you aren't familiar with Arch, this is essentially a bash script where build() and package() are run to build the files, and then install them into the $pkgdir to later tar them up.) + +Starting with qemu v2.10.0, Windows crashes randomly with a bluescreen about CRITICAL_STRUCTURE_CORRUPTION. I also tested the git heads f90ea7ba7c, 861cd431c9 and e822e81e35, before I went back to v2.9.0, which is running stable for over 50 hours right now. + +During my tests I found that locking the memory pages alleviates the problem somewhat, but never completely avoids it. However, with the crashes occuring randomly, that could as well be false conclusions; I had crashes within minutes after boot with that too. + +I will now start `git bisect`ing; if you have any other suggestions on what I could try or possible patches feel free to leave them with me. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1729 b/results/classifier/deepseek-2/output/hypervisor/1729 new file mode 100644 index 000000000..ba83385e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1729 @@ -0,0 +1,48 @@ + +mremap fails with EFAULT if address range overlaps with stack guard +Description of problem: +When running 32-bit user-static on 64-bit host, `mremap` behave differently from the kernel. This difference let programs that call `pthread_getattr_np` on musl-libc to run into a loop on repeated calling `mremap`. + +https://git.musl-libc.org/cgit/musl/plain/src/thread/pthread_getattr_np.c + +``` c + while (mremap(p-l-PAGE_SIZE, PAGE_SIZE, 2*PAGE_SIZE, 0)==MAP_FAILED && errno==ENOMEM) + l += PAGE_SIZE; +``` +Steps to reproduce: +Compile the following program against musl-libc arm 32-bit, and run it in qemu-user-static on x86_64 host. + +``` c +#define _GNU_SOURCE +#include <pthread.h> + +int main(int argc, char *argv[]) { + pthread_attr_t attr; + return pthread_getattr_np(pthread_self(), &attr); +} +``` + +For example, on x86_64 fedora 38 with podman and qemu-user-static installed, we can reproduce this with alpine container: + +``` +$ podman run --rm -it --arch arm/v7 docker.io/library/alpine:latest + +/ # apk add alpine-sdk + +...... + +/ # cat test.c +#define _GNU_SOURCE +#include <pthread.h> + +int main(int argc, char *argv[]) { + pthread_attr_t attr; + return pthread_getattr_np(pthread_self(), &attr); +} + +/ # gcc test.c + +/ # ./a.out +``` +Additional information: +Original thread on musl mail list where this was initially reported: https://www.openwall.com/lists/musl/2017/06/15/9 diff --git a/results/classifier/deepseek-2/output/hypervisor/1732177 b/results/classifier/deepseek-2/output/hypervisor/1732177 new file mode 100644 index 000000000..bfff74eed --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1732177 @@ -0,0 +1,6 @@ + +SBSA ACS test freezes inside qemu-system-aarch64 + +In an effort to get Windows 10 for ARM64 (which is supposed to boot on SBSA/SBBR-compliant platforms) to boot inside qemu, I tried to run the SBSA ACS test suite. I used the UEFI image from the latest Linaro snapshot, and built the SBSA ACS UEFI application from https://github.com/ARM-software/sbsa-acs myself using a Linaro aarch64 compiler. + +Test #8 causes an infinite exception loop, as the exception vectors themselves somehow become inaccessible, and accessing them triggers another exception to be handled by the same vector. (With some older Linaro UEFI images, the hard lockup is avoided, and the SBSA UEFI app crashes instead.) If I disable that test, the testsuite locks up in other tests in very similar ways. We aren't even able to get a pass/fail score from the app because of this. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1733 b/results/classifier/deepseek-2/output/hypervisor/1733 new file mode 100644 index 000000000..c4b9d8444 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1733 @@ -0,0 +1,4 @@ + +[riscv-pmp]: PMP_is_locked function has redundant top pmp check +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1735049 b/results/classifier/deepseek-2/output/hypervisor/1735049 new file mode 100644 index 000000000..fced215d8 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1735576 b/results/classifier/deepseek-2/output/hypervisor/1735576 new file mode 100644 index 000000000..d5d3e1e24 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1738507 b/results/classifier/deepseek-2/output/hypervisor/1738507 new file mode 100644 index 000000000..c68f9510d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1738507 @@ -0,0 +1,10 @@ + +qemu sometimes stuck when booting windows 10 + +I am using qemu-2.10.1, or actually libvirt, to create a virtual machine, running microsoft windows 10 pro operating system. +It installed fine and was actually working, however sometimes when trying to boot the vm, the whole boot process gets stuck. +For some reason, it seemed to happen only when enough physical memory is taken so that, when booting a windows vm that has 4gb of available ram, host starts swapping some other processes. It is not always happening there, but often it happens, and I do not remember seeing any case of this happening when not swapping, maybe a kind of a timing issue? +When this happens, I usually try to hard reset the machine by libvirt reset command or equivalent system_reset on qemu monitor, however the whole reset does not happen, and the command is a noop. That makes me think it is a qemu bug, not windows refusing operation. At the time of this event, qemu monitor and spice server are working correctly, are not stuck, and even doing things like system reset does not result in a monitor hang. It is also possible to quit qemu normally. +I tried to workaround the bug by guessing what may cause it. Switched from bios to uefi, changed virtio-scsi to ahci temporarily, and disabled virtio-balloon in case it would be buggy, with no visible change. +I will attach a libvirt log, because it contains qemu command line. I will also attach an example qemu backtrace. +From what i know, both vcpu threads are working normally, at least none of them is stuck in a vcpu, nor deadlocked, etc. So backtrace could be different each time I tried to get it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1739413 b/results/classifier/deepseek-2/output/hypervisor/1739413 new file mode 100644 index 000000000..63a9dc6e6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1752 b/results/classifier/deepseek-2/output/hypervisor/1752 new file mode 100644 index 000000000..88c465b5d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1752 @@ -0,0 +1,23 @@ + +QEMU bug: csrw `MIE_MEIE | MIE_MSIE | MIE_MTIE` to sie changes mie +Description of problem: +QEMU bug: csrw `MIE_MEIE | MIE_MSIE | MIE_MTIE` to sie changes mie. + +**Only csrw causes this bug. csrs/csrc have no effect.** +Steps to reproduce: +output from my test program: +``` +[firmware_main] Clear mie +[firmware_main] mie is 0x0 +[firmware_main] sie is 0x0 +[firmware_main] Set MIE_SEIE | MIE_STIE | MIE_SSIE | MIE_MEIE for mie +[firmware_main] mie is 0xa22 +[firmware_main] sie is 0x0 +[firmware_main] mideleg is 0x0 +[firmware_main] Set MIE_SEIE | MIE_STIE | MIE_SSIE for mideleg +[firmware_main] mie is 0xa22 +[firmware_main] sie is 0x222 +[firmware_main] Set MIE_SSIE for sie +[firmware_main] mie is 0x800 +[firmware_main] sie is 0x0 +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/1754597 b/results/classifier/deepseek-2/output/hypervisor/1754597 new file mode 100644 index 000000000..e06660a8c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1754597 @@ -0,0 +1,35 @@ + +qemu-system-x86_64 broken on ubuntu 17.10 + +I have run a virtual machine over the past three years without problems, but the update to Ubuntu 17.10 broke it: the machine falls into an infinite boot loop. + +$ qemu-system-x86_64 --version +QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.5) + +$ sudo qemu-system-x86_64 -enable-kvm -usb \ + -chardev stdio,id=char0 \ + -device usb-host,vendorid=0x056a,productid=0x00c6 \ + -device usb-host,vendorid=0x04a9,productid=0x2220 \ + -soundhw all \ + -m 2048 -cpu core2duo -machine q35 \ + -smp 2 \ + -device usb-mouse \ + -vga std \ + -device isa-applesmc,osk="CONFIDENTIAL" \ + -smbios type=2 \ + -device ide-drive,bus=ide.0,drive=HDD \ + -drive id=HDD,if=none,cache=none,file=hdd.img \ + -device ide-drive,bus=ide.3,drive=ScrapHDD \ + -drive id=ScrapHDD,if=none,cache=none,file=scrap.img \ + -netdev tap,id=net0,ifname=tap0,script=no \ + -device e1000,netdev=net0,id=nic0,mac=00:aa:00:60:00:01 + +$ uname -a +Linux behemoth 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 17.10 +Release: 17.10 +Codename: artful \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1756538 b/results/classifier/deepseek-2/output/hypervisor/1756538 new file mode 100644 index 000000000..c4b2d1d2d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1756538 @@ -0,0 +1,14 @@ + +Minimal Ubuntu vs. Debian differences + +I'm using Qemu on Ubuntu (minimal) and Debian (minimal) on Android (Arch64) via Linux Deploy to run Windows guests. Here's a few issues I encountered: + +1) Qemu on (minimal) Debian 9 and Ubuntu cannot run Windows 7-10 guests (only Windows XP and below) because there's a black screen after the boot menu. Qemu on Debian 10, however, can run Windows 7. Incidentally, these distros run on the host in bios compatibility mode instead of UEFI. Ubuntu Desktop (full distro) on other hosts does not display the black screen when running Qemu. + +2) Qemu on Debian 9-10 (minimal) does not display fullscreen - but Ubuntu minimal does display full-screen. + +3) Qemu on Limbo PC Emulator and on Debian 9-10 only run windows guests at 1 GHz using the default Qemu CPU, but Ubuntu runs windows guests at 2 GHz using the default Qemu CPU. + +4) Enable KVM doesn't work, and virtualization isn't detected through Limbo PC Emulator and minimal Linux distros running on Android - perhaps is a problem with running Linux distros via Linux Deploy using Chroot on Android (not so much a Qemu-KVM issue) and failing to detect ARMv8-A CPUs that are indeed capable of virtualization. + +Can anyone explain these differences? I believe they are all using the latest versions of Qemu. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1757323 b/results/classifier/deepseek-2/output/hypervisor/1757323 new file mode 100644 index 000000000..aa56f4424 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1757323 @@ -0,0 +1,85 @@ + +blue screen running windows 10 install DVD on qemu + +i get a blue screen at the first screen of the windows 10 DVD setup (Win10_1709_English_x64.iso, available from MS). + +The DVD boots fine, and gets to the first dialog: http://codewithoutborders.com/posted/qemu1.png +and then if i just wait a minute of so it blue screen's. +either DRIVER IRQL NOT LESS OR EQUAL: http://codewithoutborders.com/posted/qemu2.png +or KMODE EXCEPTION NOT HANDLED: http://codewithoutborders.com/posted/qemu3.png + + + + +the qemu command-line is: + +/usr/bin/qemu-system-x87_64 \ + -boot strict=on \ + -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-generic/monitor.sock,server,nowait \ + -chardev spicevmc,id=charchannel0,name=vdagent \ + -cpu core2duo,+lahf_lm,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,kvm=off \ + -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 ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 \ + -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 \ + -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \ + -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ + -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ + -drive file=/mnt/ISOs/Win10_1709_English_x64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ + -global kvm-pit.lost_tick_policy=discard \ + -global PIIX4_PM.disable_s3=1 \ + -global PIIX4_PM.disable_s4=1 \ + -m 4096 \ + -machine pc-i440fx-xenial,accel=tcg,usb=off \ + -mon chardev=charmonitor,id=monitor,mode=control \ + -msg timestamp=on \ + -name generic \ + -nodefaults \ + -no-hpet \ + -no-shutdown \ + -no-user-config \ + -realtime mlock=off \ + -rtc base=utc,driftfix=slew \ + -S \ + -smp 2,sockets=2,cores=1,threads=1 \ + -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \ + -uuid 3902a801-42dd-4bf2-8f3a-cbc68f4f8564 + + +$ /usr/bin/qemu-system-x87_64 --version +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24), Copyright (c) 2003-2008 Fabrice Bellard + +$ uname -a +Linux host 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +$ cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 15 +model name : Intel(R) Core(TM)2 Quad CPU @ 2.66GHz +stepping : 7 +microcode : 0x66 +cpu MHz : 2671.406 +cache size : 4096 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 10 +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 lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti retpoline tpr_shadow dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 +bogomips : 5342.81 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +... 3 more times \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1758819 b/results/classifier/deepseek-2/output/hypervisor/1758819 new file mode 100644 index 000000000..694f8a072 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1761535 b/results/classifier/deepseek-2/output/hypervisor/1761535 new file mode 100644 index 000000000..cc35ccf65 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1761535 @@ -0,0 +1,37 @@ + +qemu-aarch64-static docker arm64v8/openjdk coredump + +I am using qemu-aarch64-static to run the arm64v8/openjdk official image on my x86 machine. Using QEMU master, I immediately hit a bug which hangs the container. With Ubuntu default version qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24) and qemu-aarch64 version 2.11.1 (v2.11.1-dirty) the hang does not take place. + +To reproduce (and get to the core dump): + +$ /tmp/tmptgyg3nvh/qemu-aarch64-static/qemu-aarch64-static -version +qemu-aarch64 version 2.11.91 (v2.12.0-rc1-5-g47d3b60-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ docker run -it -v /tmp/tmptgyg3nvh/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/openjdk /bin/bash +root@bf75cf45d311:/# javac +Usage: javac <options> <source files> +where possible options include: + -g Generate all debugging info +<...snip...> + @<filename> Read options and filenames from file + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +...TERMINAL HANGS... + + +To get the core dump, In a separate terminal: + +# snapshot the file system of the hung image +$ docker commit $(docker ps -aqf "name=latest_qemu") qemu_coredump + +# connect with known working qemu +$ docker run -t -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -i qemu_coredump /bin/bash + +$$ ls -lat +total 10608 +<snip> +-rw-r--r-- 1 root root 10792960 Mar 29 18:02 qemu_bash_20180329-180251_1.core +drwxrwxrwt 5 root root 4096 Mar 29 18:02 tmp +<snip> \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1762 b/results/classifier/deepseek-2/output/hypervisor/1762 new file mode 100644 index 000000000..fa32851ec --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1762 @@ -0,0 +1,84 @@ + +Linux RTC issues possibly with RTC_UIE_ON, RTC_UIE_OFF +Description of problem: +Running: + +``` +hwclock --hctosys +``` + +as root, under the running VM using a UEFI bios image, I get: + +``` +hwclock: select() to /dev/rtc0 to wait for clock tick timed out +``` + +When running the same command on the same disk image but without UEFI, +that is, just using the SeaBIOS bios, everything works fine. + +Running + +``` +hwclock --hctosys --directisa +``` + +works fine, too. + +Running the (compiled) kernel test utility: + + +``` +/usr/src/linux/tools/testing/selftests/rtc/rtctest.c + +``` + + +``` +TAP version 13 +1..8 +# Starting 8 tests from 2 test cases. +# RUN rtc.date_read ... +# rtctest.c:49:date_read:Current RTC date/time is 10/07/2023 14:02:11. +# OK rtc.date_read +ok 1 rtc.date_read +# RUN rtc.date_read_loop ... +# rtctest.c:88:date_read_loop:Continuously reading RTC time for 30s (with 11ms breaks after every read). +# rtctest.c:115:date_read_loop:Performed 2752 RTC time reads. +# OK rtc.date_read_loop +ok 2 rtc.date_read_loop +# RUN rtc.uie_read ... +# uie_read: Test terminated by timeout +# FAIL rtc.uie_read +not ok 3 rtc.uie_read +# RUN rtc.uie_select ... +# rtctest.c:164:uie_select:Expected 0 (0) != rc (0) +# uie_select: Test terminated by assertion +# FAIL rtc.uie_select +not ok 4 rtc.uie_select +# RUN rtc.alarm_alm_set ... +# rtctest.c:202:alarm_alm_set:Alarm time now set to 14:02:52. +# rtctest.c:214:alarm_alm_set:Expected 0 (0) != rc (0) +# alarm_alm_set: Test terminated by assertion +# FAIL rtc.alarm_alm_set +not ok 5 rtc.alarm_alm_set +# RUN rtc.alarm_wkalm_set ... +# rtctest.c:258:alarm_wkalm_set:Alarm time now set to 10/07/2023 14:02:57. +# rtctest.c:268:alarm_wkalm_set:Expected 0 (0) != rc (0) +# alarm_wkalm_set: Test terminated by assertion +# FAIL rtc.alarm_wkalm_set +not ok 6 rtc.alarm_wkalm_set +# RUN rtc.alarm_alm_set_minute ... +# rtctest.c:304:alarm_alm_set_minute:Alarm time now set to 14:03:00. +# rtctest.c:316:alarm_alm_set_minute:Expected 0 (0) != rc (0) +# alarm_alm_set_minute: Test terminated by assertion +# FAIL rtc.alarm_alm_set_minute +not ok 7 rtc.alarm_alm_set_minute +# RUN rtc.alarm_wkalm_set_minute ... +# rtctest.c:360:alarm_wkalm_set_minute:Alarm time now set to 10/07/2023 14:05:00. +# rtctest.c:370:alarm_wkalm_set_minute:Expected 0 (0) != rc (0) +# alarm_wkalm_set_minute: Test terminated by assertion +# FAIL rtc.alarm_wkalm_set_minute +not ok 8 rtc.alarm_wkalm_set_minute +# FAILED: 2 / 8 tests passed. +# Totals: pass:2 fail:6 xfail:0 xpass:0 skip:0 error:0 +# diff --git a/results/classifier/deepseek-2/output/hypervisor/1767146 b/results/classifier/deepseek-2/output/hypervisor/1767146 new file mode 100644 index 000000000..fa13485fa --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1767146 @@ -0,0 +1,36 @@ + +No ACPI-table found, option -M 1.6 not found either + +Currently writing a small kernel, when trying to detect memory blocks that contain ACPI information, no such block is found. When ran in Oracle Virtualbox, code runs flawlessly. + +Code that is detecting the ACPI-Info (with a bit of debug-output): + +``` +multiboot_memory_map32_t* map = (multiboot_memory_map32_t*)mmap; +for (uint32_t i = 0; i < size; i++) { + Termutils::cout << map[i].type << "type of block "; + if (mmap[i].type == MULTIBOOT_MEMORY_ACPI_RECLAIMABLE) { + Termutils::cout << "WE ARE INSIDE\n"; + fadt = (FADT*)(map[i].base_addr_low); + //break; + } + if (i % 9 == 0) { + Termutils::cout << "\n"; + } +} +``` + + +command qemu is run with: + +qemu-img create build/objects/test 500M +qemu-system-i386 -hda $(APP_DIR)/clinl.iso -hdb ./build/objects/test + + +The iso-image is (zipped) included as attachment. + + +qemu-system-i386 --version: + +QEMU emulator version 2.10.1(qemu-2.10.1-3.fc27) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1774605 b/results/classifier/deepseek-2/output/hypervisor/1774605 new file mode 100644 index 000000000..3a747d0ce --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1774605 @@ -0,0 +1,41 @@ + +PowerPC guest does not emulate L2 and L3 cache for KVM vCPUs + +PowerPC KVM guest does not emulate L2 and L2 caches for vCPU, it would be good to have them enabled if not any known issues/limitation already with PowerPC. + +Host Env: +kernel: 4.17.0-rc7-00045-g0512e0134582 +qemu: v2.12.0-923-gc181ddaa17-dirty +#libvirtd -V +libvirtd (libvirt) 4.4.0 + + +Guest Kernel: +# uname -a +Linux atest-guest 4.17.0-rc7-00045-g0512e0134582 #9 SMP Fri Jun 1 02:55:50 EDT 2018 ppc64le ppc64le ppc64le GNU/Linux + +Guest: +# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 16 +On-line CPU(s) list: 0-15 +Thread(s) per core: 8 +Core(s) per socket: 2 +Socket(s): 1 +NUMA node(s): 1 +Model: 2.1 (pvr 004b 0201) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 64K +L1i cache: 32K +NUMA node0 CPU(s): 0-15 + + + +background: x86 enabling cpu L2 cache bydefault and L3 cache on demand for kvm guest +and claims performance improvement as vcpus can be +benefited with lesser `vmexits due to guest send IPIs.` with L3 cache enabled, below was patch for same. + +https://git.qemu.org/?p=qemu.git;a=commit;h=14c985cffa6cb177fc01a163d8bcf227c104718c \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1775366 b/results/classifier/deepseek-2/output/hypervisor/1775366 new file mode 100644 index 000000000..7cc929007 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1775366 @@ -0,0 +1,14 @@ + + [Feature request] qemu-ga - Allow unexpected parameter + +It whould be nice if the qemu-ga allowed received messages to contain fields which is not part of the spec. In my example I have a host which sends the following request: + +{"execute":"guest-exec","arguments":{"path":"prl_nettool","capture-output":true,"execute-in-shell":false,"arg":[...]}} + +Right now this request is rejected with the following error: + +{"error": {"class": "GenericError", "desc": "Parameter 'execute-in-shell' is unexpected"}} + +My situation is the hosting provider I use does have some customized solution which sends some extra arguments. I have manually patched my qemu-ga so it accepts the "execute-in-shell" parameter but I don't think this should be necessary. + +Instead of "Error" it should just be a "warning" returned to the user of qemu-ga but the call should still be executed. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1776 b/results/classifier/deepseek-2/output/hypervisor/1776 new file mode 100644 index 000000000..4a236cd3f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1776 @@ -0,0 +1,2 @@ + +qemu-armel SEGFAULTs when trying to map a commpage on armel diff --git a/results/classifier/deepseek-2/output/hypervisor/1777236 b/results/classifier/deepseek-2/output/hypervisor/1777236 new file mode 100644 index 000000000..8f99b5781 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1777236 @@ -0,0 +1,12 @@ + +NVME is missing support for mandatory features through "Get/Set Feature" command + +The following are features which are marked as mandatory by the 1.2 specification (NVMe 1.2, Section 5.14.1, Figure 108) as currently not implemented + - 0x1 Arbitration + - 0x2 Power Management + - 0x4 Temperature Threshold + - 0x5 Error Recovery + - 0x6 Interrupt Coalescing + - 0x7 Interrupt Vector Configuration + - 0x8 Write Atomicity Normal + - 0x9 Asynchronous Event Configuration \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1777293 b/results/classifier/deepseek-2/output/hypervisor/1777293 new file mode 100644 index 000000000..eb75aa5a4 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1777301 b/results/classifier/deepseek-2/output/hypervisor/1777301 new file mode 100644 index 000000000..398508295 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1777301 @@ -0,0 +1,58 @@ + +Boot failed after installing Checkpoint Pointsec FDE + +Boot failed after installing Checkpoint Pointsec FDE + + +Hi, +I installed Windows 10 64-bit guest on CentOS 7. Everything works great as expected. +However after installing CheckPoint AlertSec full disk encryption, the guest failed to boot. + +The following error is displayed in qemu log file. +KVM internal error. Suberror: 1 +emulation failure + + + + + +Installed Software +[root@sesamvmh01 qemu]# yum list installed | grep qemu +ipxe-roms-qemu.noarch 20170123-1.git4e85b27.el7_4.1 @base +libvirt-daemon-driver-qemu.x86_64 3.9.0-14.el7_5.5 @updates +qemu-guest-agent.x86_64 10:2.8.0-2.el7 @base +qemu-img-ev.x86_64 10:2.3.0-29.1.el7 @qemu-kvm-rhev +qemu-kvm-common-ev.x86_64 10:2.3.0-29.1.el7 @qemu-kvm-rhev +qemu-kvm-ev.x86_64 10:2.3.0-29.1.el7 @qemu-kvm-rhev + +# uname -r +3.10.0-862.3.2.el7.x86_64 + +CPU info: +processor : 0..3 +vendor_id : GenuineIntel +cpu family : 6 +model : 30 +model name : Intel(R) Xeon(R) CPU X3430 @ 2.40GHz +stepping : 5 +microcode : 0x7 +cpu MHz : 1200.000 +cache size : 8192 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +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 nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm ida +bogomips : 4799.98 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +Please also check attached logs. I am new to qemu-kvm so please don't hesitate to ask missing info. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1778966 b/results/classifier/deepseek-2/output/hypervisor/1778966 new file mode 100644 index 000000000..a2b63a749 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1778966 @@ -0,0 +1,6 @@ + +Windows 1803 and later crashes on KVM + +For a bionic host, using the current public kvm modules, KVM is not capable of booting a WindowsInsider or msdn Windows 1803 iso. In stallign from an ISO from a started windows 2016 guest results in an unbootable and unrepairable guest. + +The hardware is a threadripper 1920x with 32GB of main memory, disk mydigital BPX SSD and WD based 4 column RAID 5 via mdadm. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1779649 b/results/classifier/deepseek-2/output/hypervisor/1779649 new file mode 100644 index 000000000..9f20a0c7c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1779649 @@ -0,0 +1,8 @@ + +Suspending a domain works with a 3.16 gues kernel but not with a 4.16 one + +Suspending a domain with `systemctl suspend` works with a guest 3.16 kernel (jessie), the domain goes into `pmsuspend` in libvirt but doesn't work anymore with a 4.16 one (sid) where: + - With a QXL card: the spice display just goes black and the domain stays `running` in libvirt but is "dead" + - With a VGA card: the screen goes black and comes back immediately, the domain stays fine + +Qemu: Master, 281bd281222776229d5dbf84d1a5c6d8d9d2a34b \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1780928 b/results/classifier/deepseek-2/output/hypervisor/1780928 new file mode 100644 index 000000000..a118e1f0d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1780928 @@ -0,0 +1,31 @@ + +v2.12.0-2321-gb34181056c: vcpu hotplug crashes qemu-kvm with segfault + +vcpu hotplug crashes upstream qemu(v2.12.0-2321-gb34181056c), vcpu hotplug works fine in v2.12.0-rc4. + +Host: Power8, kernel: 4.18.0-rc2-00037-g6f0d349d922b +Guest: Power8, kernel: 4.18.0-rc3-00183-gc42c12a90545 (base image: fedora27 ppc64le) + +/usr/share/avocado-plugins-vt/build/qemu/ppc64-softmmu/qemu-system-ppc64 -M pseries,accel=kvm,max-cpu-compat=power8 -m 8192 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/avocado/data/avocado-vt/images/jeos-27-ppc64le.qcow2,format=qcow2,if=none,id=drive1 -device scsi-hd,drive=drive1,bus=scsi0.0 -smp 1,cores=1,threads=1,sockets=1,maxcpus=8 -serial /dev/pts/0 -monitor stdio -vga none -nographic -kernel /home/kvmci/linux/vmlinux -append 'root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug' -nic user,model=virtio-net-pci +QEMU 2.12.50 monitor - type 'help' for more information +(qemu) device_add host-spapr-cpu-core,id=core1,core-id=1 +Segmentation fault (core dumped) + + +Guest initial cpu: +# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 1 +On-line CPU(s) list: 0 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 1 +NUMA node(s): 1 +Model: 2.1 (pvr 004b 0201) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 64K +L1i cache: 32K +NUMA node0 CPU(s): 0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1781211 b/results/classifier/deepseek-2/output/hypervisor/1781211 new file mode 100644 index 000000000..f960c7489 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1781211 @@ -0,0 +1,16 @@ + +HAXM acceleration does not work at all. + +I have qemu windows build 2.12.90, haxm 7.2.0. Ubuntu, nor arch linux does not works when i turn on hax acceleration. Permanent kernel panics, black screen freezing and other crashes happens when i run qemu. +Qemu crashed with hax - when i ran it from iso. It crashed on already installed system - it's not matters. + +Versions: +archlinux-2018.07.01-x86_64 +ubuntu-18.04-live-server-amd64.iso + +I run qemu-system-x86_64.exe binary. + +My CPU: +core i7 2600k + +See screenshot \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1785308 b/results/classifier/deepseek-2/output/hypervisor/1785308 new file mode 100644 index 000000000..68018d28c --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1788665 b/results/classifier/deepseek-2/output/hypervisor/1788665 new file mode 100644 index 000000000..62890e335 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1788665 @@ -0,0 +1,43 @@ + +Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection + +Windows 10 (1803) VM using VGA passthrough via qemu script. + +After upgrading Windows 10 Pro VM to version 1803, or possibly after applying the March/April security updates from Microsoft, the VM would show low 2D graphics performance (sluggishness in 2D applications and low Passmark results). + +Turning off Spectre vulnerability protection in Windows remedies the issue. + +Expected behavior: +qemu/kvm hypervisor to expose firmware capabilities of host to guest OS - see https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms + +Background: + +Starting in March or April Microsoft began to push driver updates in their updates / security updates. See https://support.microsoft.com/en-us/help/4073757/protect-your-windows-devices-against-spectre-meltdown + +One update concerns the Intel microcode - see https://support.microsoft.com/en-us/help/4100347. It is activated by default within Windows. + +Once the updates are applied within the Windows guest, 2D graphics performance drops significantly. Other performance benchmarks are not affected. + +A bare metal Windows installation does not display a performance loss after the update. See https://heiko-sieger.info/low-2d-graphics-benchmark-with-windows-10-1803-kvm-vm/ + +Similar reports can be found here: +https://www.reddit.com/r/VFIO/comments/97unx4/passmark_lousy_2d_graphics_performance_on_windows/ + +Hardware: + +6 core Intel Core i7-3930K (-MT-MCP-) + +Host OS: +Linux Mint 19/Ubuntu 18.04 +Kernel: 4.15.0-32-generic x86_64 +Qemu: QEMU emulator version 2.11.1 +Intel microcode (host): 0x714 +dmesg | grep microcode +[ 0.000000] microcode: microcode updated early to revision 0x714, date = 2018-05-08 +[ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714 +[ 2.813340] microcode: Microcode Update Driver: v2.2. + +Note: I manually updated the Intel microcode on the host from 0x713 to 0x714. However, both microcode versions produce the same result in the Windows guest. + +Guest OS: +Windows 10 Pro 64 bit, release 1803 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1793539 b/results/classifier/deepseek-2/output/hypervisor/1793539 new file mode 100644 index 000000000..680c64e8b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1793539 @@ -0,0 +1,10 @@ + +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 + +During the build of gedit for RISC-V this error occurs: + +$ qemu-riscv64 -E LD_LIBRARY_PATH=gedit/.libs ./gedit/.libs/gedit +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600009e4 + +https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/gedit/standard/riscv64 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1797 b/results/classifier/deepseek-2/output/hypervisor/1797 new file mode 100644 index 000000000..d0e521b68 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1797 @@ -0,0 +1,4 @@ + +RAM-backed snapshotting +Additional information: +And thank you for QEMU! 🙂 diff --git a/results/classifier/deepseek-2/output/hypervisor/1798057 b/results/classifier/deepseek-2/output/hypervisor/1798057 new file mode 100644 index 000000000..799b561ef --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1798057 @@ -0,0 +1,29 @@ + +Not able to start instances larger than 1 TB + +Specs: + +CPU: Intel(R) Xeon(R) Gold 6132 CPU @ 2.60GHz +OS: Ubuntu 18.04 AMD64 +QEMU: 1:2.11+dfsg-1ubuntu7.6 (Ubuntu Bionic Package) +Openstack: Openstack Queens (Ubuntu Bionic Package) +Libvirt-daemon: 4.0.0-1ubuntu8.5 +Seabios: 1.10.2-1ubuntu1 + + +The Problem: +We are not able to start instances, which have a memory size over 1 TB. +After starting the instance, they shortly lock up. Starting guests with a lower amount of RAM works +perfectly. We dealt with the same problem in the past with an older Qemu Version (2.5) by patching some source files according to this patch: + +https://git.centos.org/blob/rpms!!qemu-kvm.git/34b32196890e2c41b0aee042e600ba422f29db17/SOURCES!kvm-fix-guest-physical-bits-to-match-host-to-go-beyond-1.patch + + +I think we now have somewhat the same problem here, however the source base changed and I'am not able to find the corresponding snippet to patch this. + +Also, guests show a wrong physical address size which is probably the cause of the lock ups on high memory guests: +root@debug:~# grep physical /proc/cpuinfo +physical id : 0 +address sizes : 40 bits physical, 48 bits virtual + +Any way to fix this? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1798451 b/results/classifier/deepseek-2/output/hypervisor/1798451 new file mode 100644 index 000000000..1afa18b7b --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1802150 b/results/classifier/deepseek-2/output/hypervisor/1802150 new file mode 100644 index 000000000..614793267 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1809 b/results/classifier/deepseek-2/output/hypervisor/1809 new file mode 100644 index 000000000..993c2c615 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1809144 b/results/classifier/deepseek-2/output/hypervisor/1809144 new file mode 100644 index 000000000..e09a04524 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1811862 b/results/classifier/deepseek-2/output/hypervisor/1811862 new file mode 100644 index 000000000..dea9ce4bf --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1811862 @@ -0,0 +1,39 @@ + +microcode version stays 0x1 even if -cpu host is used + +The microcode version of my host cpu has the following version: + +grep microcode /proc/cpuinfo | head -1 +microcode : 0x3d + +while trying to run ESXi in an nested VM, the boot bailed out with +error message that at least microcode version 0x19 is needed. It +seems they have introduced such a check on certain CPU types. + +The VM in question is using the "host-passthrough" option in libvirt +and the qemu command line reads as this: + +21172 ? Sl 0:09 /usr/libexec/qemu-kvm -name guest=hpe-env-client1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-33-hpe-env-client1/master-key.aes -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off -cpu host <rest stripped> + +Running a regular Linux VM with `host-passthrough` shows that the +microcode version is still reported as 0x1. + +Within the VM: + +[root@hpe-env-client1 ~]# cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 63 +model name : Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz +stepping : 2 +microcode : 0x1 +cpu MHz : 2397.222 + + +My impression is qemu should copy the hosts microcode version in this case? + +Running Qemu von RHEl8 beta here. + +[root@3parserver ~]# /usr/libexec/qemu-kvm --version +QEMU emulator version 2.12.0 (qemu-kvm-2.12.0-41.el8+2104+3e32e6f8) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1813165 b/results/classifier/deepseek-2/output/hypervisor/1813165 new file mode 100644 index 000000000..a47f59414 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1813165 @@ -0,0 +1,36 @@ + +KVM internal error. Suberror: 1 emulation failure + +Hello Devs. + +Having problems getting VM to run with qemu 3.1.0. + +2019-01-24 13:46:08.648+0000: starting up libvirt version: 4.10.0, qemu version: 3.1.0, kernel: 4.14.94, hostname: one.lordcritical.de +LC_ALL=C PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin HOME=/root USER=root QEMU_AUDIO_DRV=none /usr/bin/kvm -name guest=one-266,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-one-266/master-key.aes -machine pc-i440fx-2.9,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Client-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,ssbd=on,xsaves=on,pdpe1gb=on -m 1024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid b219b45d-a2f0-4128-a948-8673a7abf968 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=21,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 -drive file=/var/lib/one//datastores/0/266/disk.0,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/var/lib/one//datastores/0/266/disk.1,format=raw,if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=02:00:00:76:69:85,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 0.0.0.0:266 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on +char device redirected to /dev/pts/1 (label charserial0) +KVM internal error. Suberror: 1 +emulation failure +EAX=00000001 EBX=000f7c2c ECX=00000001 EDX=00000001 +ESI=00006a26 EDI=3ffbdc48 EBP=000069e6 ESP=000a8000 +EIP=000fd057 EFL=00010016 [----AP-] CPL=0 II=0 A20=1 SMM=1 HLT=0 +ES =0010 00000000 ffffffff 00c09300 +CS =0000 00000000 00000fff 00809b00 +SS =0010 00000000 ffffffff 00c09300 +DS =0010 00000000 ffffffff 00c09300 +FS =0010 00000000 ffffffff 00c09300 +GS =0010 00000000 ffffffff 00c09300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 10387cfe 0000fe6c +IDT= 0010387c 00003810 +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000fffecffc DR7=000000000e1e0400 +EFER=0000000000000000 +Code=cb 66 ba 4d d0 0f 00 e9 c8 fe bc 00 80 0a 00 e8 31 3a ff ff <0f> aa fa fc 66 ba 66 d0 0f 00 e9 b1 fe f3 90 f0 0f ba 2d ac 3b 0f 00 00 72 f3 8b 25 a8 3b +2019-01-24T13:47:39.383366Z kvm: terminating on signal 15 from pid 2708 (/usr/sbin/libvirtd) + +Someone has an idea whats going wrong here? + +thanks and cheers +t. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1813940 b/results/classifier/deepseek-2/output/hypervisor/1813940 new file mode 100644 index 000000000..14296a44a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1813940 @@ -0,0 +1,47 @@ + +kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device + +Latest QEMU master fails to run with too many MMIO devices specified. + +After patch 3ac7d43a6fb [1] QEMU just prints an error message and exits. +> kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device + +This is reproducible e.g. with the following setup: + +qemu-3.1.50-dirty \ + -machine pc-i440fx-2.7,accel=kvm \ + -cpu host -m 4096 \ + -smp 2,sockets=2,cores=1,threads=1 \ + -drive file=freebsd_vm_1.qcow2,format=qcow2,if=none,id=bootdr \ + -device ide-hd,drive=bootdr,bootindex=0 \ + -device virtio-scsi-pci,id=vc0 \ + -device virtio-scsi-pci,id=vc1 \ + -device virtio-scsi-pci,id=vc2 \ + -device virtio-scsi-pci,id=vc3 \ + +Running with just 3 Virtio-SCSI controllers seems to work fine, adding more than that causes the error above. Note that this is not Virtio-SCSI specific. I've also reproduced this without any Virtio devices whatsoever. + +strace shows the following ioctl chain over and over: + +145787 ioctl(11, KVM_UNREGISTER_COALESCED_MMIO, 0x7f60a4985410) = 0 +145787 ioctl(11, KVM_UNREGISTER_COALESCED_MMIO, 0x7f60a4985410) = 0 +145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = 0 +145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) +145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) +145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) +145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) +145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) +145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) +145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) +145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) + +Which suggests there's some kind of MMIO region leak. + +[1] +commit 3ac7d43a6fbb5d4a3d01fc9a055c218030af3727 +Author: Paolo Bonzini <email address hidden> +AuthorDate: Wed Nov 28 17:28:45 2018 +0100 +Commit: Paolo Bonzini <email address hidden> +CommitDate: Fri Jan 11 13:57:24 2019 +0100 + + memory: update coalesced_range on transaction_commit \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1814418 b/results/classifier/deepseek-2/output/hypervisor/1814418 new file mode 100644 index 000000000..5de0c422a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1814418 @@ -0,0 +1,22 @@ + +persistent bitmap will be inconsistent when qemu crash, + +Follow these steps to reappear the bug: + +1. start qemu +2. add persistent bitmap: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}' +3. kill -9 qemu (simulate Host crash, eg. lose power) +4. restart qemu + +Now, the '{ "execute": "query-block" }' can't find the bitmap0. I can understand at this point, because the bitmap0 has not been synchronized yet. + +But, when I try to add persistent bitmap0 again: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}', It failed: + +{"id":"libvirt-42","error":{"class":"GenericError","desc":"Can't make bitmap 'bitmap0' persistent in 'drive-virtio-disk1': Bitmap with the same name is already stored"}} + +In other word, when qemu crash, the qcow2 image remain the incomplete persistent bitmap. + +--- + +qemu version: 2.12.0 and 3.1.0, other version I does not test yet. +qemu command: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,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=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,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,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1815009 b/results/classifier/deepseek-2/output/hypervisor/1815009 new file mode 100644 index 000000000..6eec684fc --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1815009 @@ -0,0 +1,8 @@ + +Qemu evdev multiple guests/host switch + +Hello, + +Qemu up to version 3.1 + +it would be nice if passed through evdev can be switched (using lctrl + rctrl) through all running guests configured for evdev and the host. Currently, only the last started guest and host can be switched only so the previously started guests can't be controlled. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1815078 b/results/classifier/deepseek-2/output/hypervisor/1815078 new file mode 100644 index 000000000..039f9d784 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1815078 @@ -0,0 +1,22 @@ + +Qemu 3.1.0 risc-v mie.MEIE + +Hello all, + +There is a bug in qemu for Risc-v, related to the mie register: when we try to set the MEIE bit (11) nothing is done, even when we are running at machine mode. + +Li a0 , 1 << 11 +Csrs mie , a0 + +And when we read mie it is as though nothing was done. + +Going through the qemu source code I was able to correct it: on file op_helper.c, line 94, the variable all_ints should be initialized with: + +uint64_t all_ints = delegable_ints | MIP_MSIP | MIP_MTIP | MIP_MEIP; + +That is, the MIP_MEIP was missing. + +I've successfully triggered uart interrupts with this patch (virt machine). + +All the best, +Pharos team \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1815911 b/results/classifier/deepseek-2/output/hypervisor/1815911 new file mode 100644 index 000000000..a6f02a0ba --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1815911 @@ -0,0 +1,20 @@ + +aptitude crashes qemu-m68k with handle_cpu_signal received signal outside vCPU context + +When building a package with sbuild on Debian, sbuild can use aptitude to resolve dependencies. + +Recently, some changes introduced to aptitude or related packages cause qemu to crash: + +(sid-m68k-sbuild)root@nofan:/# aptitude -y --without-recommends -o Dpkg::Options::=--force-confold -o Aptitude::CmdLine::Ignore-Trust-Violations=false -o Aptitude::ProblemResolver::StepScore=100 -o Aptitude::ProblemResolver::SolutionCost="safety, priority, non-default-versions" -o Aptitude::ProblemResolver::Hints::KeepDummy="reject sbuild-build-depends-core-dummy :UNINST" -o Aptitude::ProblemResolver::Keep-All-Level=55000 -o Aptitude::ProblemResolver::Remove-Essential-Level=maximum install vim +Warning: Invalid locale (please review locale settings, this might lead to problems later): + locale::facet::_S_create_c_locale name not valid +The following NEW packages will be installed: + libgpm2{a} vim vim-common{a} vim-runtime{a} xxd{a} +0 packages upgraded, 5 newly installed, 0 to remove and 1 not upgraded. +Need to get 7225 kB/7260 kB of archives. After unpacking 33.5 MB will be used. +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6019d1bf +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601b64ab +Segmentation fault +(sid-m68k-sbuild)root@nofan:/# + +The crash does not reproduce on real hardware running Debian unstable. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1816 b/results/classifier/deepseek-2/output/hypervisor/1816 new file mode 100644 index 000000000..63ede946f --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1817846 b/results/classifier/deepseek-2/output/hypervisor/1817846 new file mode 100644 index 000000000..6d4f603b0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1817846 @@ -0,0 +1,47 @@ + +Qemu 3.1 Aarch64 TLBI VAE1, x0 + +Hello, + +In my code I'm trying to remove some permissions to a 4KiB MMU descriptor. After that I invalidate the MMU with + +TLBI VAE1, x0 + +where x0 is the start of the address of the 4 KiB page. + +In Qemu 2.12 this did not work, but I worked around it with: + + + /* invalidate the address */ + TLBI VAE1, x0 + + + /*****************************************************************/ + /*****************************************************************/ + /* NOTE: THIS IS A TRICK FOR QEMU!!!!!!!!!!!! */ + /* Apparently we have to change the TTBR0_EL1 when we change a descriptor (especially to remove permissions) */ + /* Otherwise qemu (2.12) will continue with the same descriptor with permissions! **/ + /*****************************************************************/ + /*****************************************************************/ + + /* do a trick (in qemu) */ + mrs x1 , TTBR0_EL1 + + ldr x2 , =kernelTable0Table + + msr TTBR0_EL1 , x2 + + isb + + msr TTBR0_EL1 , x1 + + /* return from function */ + ret + + +That is, I just replaced the TTBR0_EL1 with a temporary value, and then restored it. (guess qemu 2.12 just needed to reload the values again). + +However, even this procedure is not working with qemu 3.1. (I just tested again with qemu 2.12 and the code works fine, with qemu 3.1 it does not). + +Thanks, +Pharos team \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1818 b/results/classifier/deepseek-2/output/hypervisor/1818 new file mode 100644 index 000000000..739992ca1 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1818207 b/results/classifier/deepseek-2/output/hypervisor/1818207 new file mode 100644 index 000000000..b79255a22 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1818937 b/results/classifier/deepseek-2/output/hypervisor/1818937 new file mode 100644 index 000000000..e98218a00 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1819 b/results/classifier/deepseek-2/output/hypervisor/1819 new file mode 100644 index 000000000..2b13611ce --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1819 @@ -0,0 +1,11 @@ + +segmentation fault for rpm -qa command on centos:centos7 linux/arm/v7 architecture for docker container in shell. +Description of problem: + +Steps to reproduce: +1. docker pull centos:centos7@sha256:6887440ab977f751d6675157b73e42428d8ac05cf244c5d09ba036cc22d40d13 //pull an image centos:centos7 linux/arm/v7 tag +2. docker run -it b22fdcc90005 //docker run in interactive mode just pulled image +3. on shell run command -\> rpm -qa. +4. docker run -it b22fdcc90005 + + WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64) and no specific platform was requested \[root@e23bc92686e8 /\]# rpm -qa Segmentation fault (core dumped) diff --git a/results/classifier/deepseek-2/output/hypervisor/1819649 b/results/classifier/deepseek-2/output/hypervisor/1819649 new file mode 100644 index 000000000..2d78c2e98 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1819649 @@ -0,0 +1,6 @@ + +Win10 Preview Build 18351 - no input + +The issue exists in both 2.12.1 and current master (built 8.3.2019). Neither keyboard nor mouse input seems to work and there's no cursor available (VNC, SPICE, SDL tested). If all the 'hv_*' flags are removed input works again. + +In the attachments you can find a simple script to reproduce it (requires the ISO path to be changed). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1821595 b/results/classifier/deepseek-2/output/hypervisor/1821595 new file mode 100644 index 000000000..7cef52b9b --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1821884 b/results/classifier/deepseek-2/output/hypervisor/1821884 new file mode 100644 index 000000000..28e1588a6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1823 b/results/classifier/deepseek-2/output/hypervisor/1823 new file mode 100644 index 000000000..acc1250ee --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1823831 b/results/classifier/deepseek-2/output/hypervisor/1823831 new file mode 100644 index 000000000..ef2ba3b03 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1824 b/results/classifier/deepseek-2/output/hypervisor/1824 new file mode 100644 index 000000000..66f3fea54 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1824 @@ -0,0 +1,2 @@ + +[8.x] qemu-user does not build under CentOS 7 any longer diff --git a/results/classifier/deepseek-2/output/hypervisor/1824053 b/results/classifier/deepseek-2/output/hypervisor/1824053 new file mode 100644 index 000000000..842f5bfa6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1824053 @@ -0,0 +1,34 @@ + +Qemu-img convert appears to be stuck on aarch64 host with low probability + +Hi, I found a problem that qemu-img convert appears to be stuck on aarch64 host with low probability. + +The convert command line is "qemu-img convert -f qcow2 -O raw disk.qcow2 disk.raw ". + +The bt is below: + +Thread 2 (Thread 0x40000b776e50 (LWP 27215)): +#0 0x000040000a3f2994 in sigtimedwait () from /lib64/libc.so.6 +#1 0x000040000a39c60c in sigwait () from /lib64/libpthread.so.0 +#2 0x0000aaaaaae82610 in sigwait_compat (opaque=0xaaaac5163b00) at util/compatfd.c:37 +#3 0x0000aaaaaae85038 in qemu_thread_start (args=args@entry=0xaaaac5163b90) at util/qemu_thread_posix.c:496 +#4 0x000040000a3918bc in start_thread () from /lib64/libpthread.so.0 +#5 0x000040000a492b2c in thread_start () from /lib64/libc.so.6 + +Thread 1 (Thread 0x40000b573370 (LWP 27214)): +#0 0x000040000a489020 in ppoll () from /lib64/libc.so.6 +#1 0x0000aaaaaadaefc0 in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:77 +#2 qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at qemu_timer.c:391 +#3 0x0000aaaaaadae014 in os_host_main_loop_wait (timeout=<optimized out>) at main_loop.c:272 +#4 0x0000aaaaaadae190 in main_loop_wait (nonblocking=<optimized out>) at main_loop.c:534 +#5 0x0000aaaaaad97be0 in convert_do_copy (s=0xffffdc32eb48) at qemu-img.c:1923 +#6 0x0000aaaaaada2d70 in img_convert (argc=<optimized out>, argv=<optimized out>) at qemu-img.c:2414 +#7 0x0000aaaaaad99ac4 in main (argc=7, argv=<optimized out>) at qemu-img.c:5305 + + +The problem seems to be very similar to the phenomenon described by this patch (https://resources.ovirt.org/pub/ovirt-4.1/src/qemu-kvm-ev/0025-aio_notify-force-main-loop-wakeup-with-SIGIO-aarch64.patch), + +which force main loop wakeup with SIGIO. But this patch was reverted by the patch (http://ovirt.repo.nfrance.com/src/qemu-kvm-ev/kvm-Revert-aio_notify-force-main-loop-wakeup-with-SIGIO-.patch). + +The problem still seems to exist in aarch64 host. The qemu version I used is 2.8.1. The host version is 4.19.28-1.2.108.aarch64. + Do you have any solutions to fix it? Thanks for your reply ! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1825311 b/results/classifier/deepseek-2/output/hypervisor/1825311 new file mode 100644 index 000000000..b8fd0e4d6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1825311 @@ -0,0 +1,4 @@ + +mips_cpu_handle_mmu_fault renders all accessed pages executable + +On MIPS, data accesses to pages mapped in the TLB result in mips_cpu_handle_mmu_fault() marking the page unconditionally executable, even if the TLB entry has the XI bit set. Later on, when there is an attempt to execute this page, no exception is generated, even though TLBXI is expected. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1826599 b/results/classifier/deepseek-2/output/hypervisor/1826599 new file mode 100644 index 000000000..4e7f8b3ac --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1826827 b/results/classifier/deepseek-2/output/hypervisor/1826827 new file mode 100644 index 000000000..4f49f4b7f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1826827 @@ -0,0 +1,56 @@ + +dtc crash; pnv_dt_serial cannot find lpc's phandle + +pnv_dt_serial has a line which is supposed to set the interrupt-parent of the "isa-serial@i3f8" node to the phandle of "lpc@0". + +To that end, it calls fdt_get_phandle as shown below: +_FDT((fdt_setprop_cell(fdt, node, "interrupt-parent", fdt_get_phandle(fdt, lpc_off)))); + +The function fdt_get_phandle fails to find the property "phandle" (or "linux,phandle") for the lpc node. Consequently, pnv_dt_serial sets the interrupt-parent to 0. + + + + + +Now boot the qemu-system-ppc64 powernv machine, and extract the fdt by using the qemu monitor's pmemsave command, taking help of the OPAL firmware's messages to locate the fdt in the physical ram. + +qemu-system-ppc64 -m 1g -machine powernv,num-chips=1 \ +-cpu power9 -smp 2,cores=2,threads=1 -accel tcg,thread=multi \ +-kernel ./vmlinux \ +-append 'disable_radix' \ +-serial mon:stdio -nographic -nodefaults + +The kernel vmlinux contains nothing but a single instruction which loops infintely, so that we can gather OPAL's messages, especially the one below: + +[ 0.168845963,5] INIT: Starting kernel at 0x20000000, fdt at 0x304b0b70 14404 bytes + + + + + +Once the fdt is dumped to a file, run the following: + +'dtc -O dtb -I dts -o out.dts dtb' + + +After a few warnings, the dtc application crashes because an assertion was fired. + +1.dts: Warning (unit_address_vs_reg): /lpcm-opb@6030000000000/lpc@0: node has a unit name, but no reg property +1.dts: Warning (simple_bus_reg): /lpcm-opb@6030000000000/lpc@0: missing or empty reg/ranges property +1.dts: Warning (avoid_unnecessary_addr_size): /ibm,opal: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property +1.dts: Warning (unique_unit_address): /interrupt-controller@0: duplicate unit-address (also used in node /memory@0) +1.dts: Warning (chosen_node_stdout_path): /chosen:linux,stdout-path: Use 'stdout-path' instead +dtc: livetree.c:575: get_node_by_phandle: Assertion `generate_fixups' failed. +Aborted (core dumped) + + + +The assertion is fired because get_node_by_phandle receives a phandle value of 0, which is unexpected, unless fixups are needed (They are not, when running the dtc command). + + + + +Back inside pnv_dt_serial, if the line that sets "interrupt-parent" for the serial device node is commented out, the dtc crash is prevented. Looking at hw/ppc/e500.c, it takes care of allocating necessary phandle values in the nodes, so a similar method can be adopted for powernv. + + +The dtb is attached. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1828 b/results/classifier/deepseek-2/output/hypervisor/1828 new file mode 100644 index 000000000..4a394b5f6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1828507 b/results/classifier/deepseek-2/output/hypervisor/1828507 new file mode 100644 index 000000000..72a3f3d84 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1829459 b/results/classifier/deepseek-2/output/hypervisor/1829459 new file mode 100644 index 000000000..9c46fd31c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1829459 @@ -0,0 +1,36 @@ + +qemu seems to lack support for pid namespace. + +# Version + +qemu-4.0.0 + +# commands used to launch qemu-aarch64 in user mode. + +printf '%s\n' ':qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-aarch64:'"${QEMU_BINFMT_FLAGS}" >/proc/sys/fs/binfmt_misc/register + +> sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin +> sudo chroot $RPI /bin/ksh -l + +# host + +Gentoo Linux amd64 + +# Guest + +Gentoo Linux aarch64 + +# The problem that I have + +"emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid argument". +"emerge" is Gentoo's package manager that compiles and installs packages. + +# How to reproduce the issue + +Execute + +unshare --pid -- echo hello world + +or + +python -c "import portage.process; portage.process.spawn(['echo', 'hello', 'world'], unshare_pid=True)" \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1830821 b/results/classifier/deepseek-2/output/hypervisor/1830821 new file mode 100644 index 000000000..5bbc64062 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1832250 b/results/classifier/deepseek-2/output/hypervisor/1832250 new file mode 100644 index 000000000..c4f218d89 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1832250 @@ -0,0 +1,58 @@ + +arm32v6/golang:1.10-alpine is broken for qemu 2.8 on MacOS cross-compilation + +FROM arm32v6/golang:1.10-alpine + +docker build -t openhorizon/ibm.gps_arm:2.0.7 -f ./Dockerfile.arm . +Sending build context to Docker daemon 110.6kB +Step 1/12 : FROM arm32v6/golang:1.10-alpine +1.10-alpine: Pulling from arm32v6/golang +05276f4299f2: Pull complete +5657e63df536: Pull complete +febca98d0249: Pull complete +5053a7aa5dea: Pull complete +d048463a3701: Pull complete +b628c679d668: Pull complete +Digest: sha256:94c5fd97b17d0e9fe89e011446bedda4784cb0af7a60494989e2a21c0dcba92f +Status: Downloaded newer image for arm32v6/golang:1.10-alpine + ---> 3110964e8c9a +Step 2/12 : RUN apk --no-cache update && apk add git + ---> Running in 14ffb11506bb +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz +v3.9.4-24-g4e2ff29bbe [http://dl-cdn.alpinelinux.org/alpine/v3.9/main] +v3.9.4-25-g65097c9cdc [http://dl-cdn.alpinelinux.org/alpine/v3.9/community] +OK: 9547 distinct packages available +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz +(1/7) Installing nghttp2-libs (1.35.1-r0) +(2/7) Installing libssh2 (1.8.2-r0) +(3/7) Installing libcurl (7.64.0-r2) +(4/7) Installing libgcc (8.3.0-r0) +(5/7) Installing expat (2.2.6-r0) +(6/7) Installing pcre2 (10.32-r1) +(7/7) Installing git (2.20.1-r0) +Executing busybox-1.29.3-r10.trigger +OK: 18 MiB in 22 packages +Removing intermediate container 14ffb11506bb + ---> 6890ea7ed09b +Step 3/12 : RUN mkdir -p /build/bin + ---> Running in 44e52d78d7b4 +Removing intermediate container 44e52d78d7b4 + ---> 0763afda41d1 +Step 4/12 : COPY src /build/src + ---> 05bab9a72a34 +Step 5/12 : WORKDIR /build + ---> Running in 5a663caff249 +Removing intermediate container 5a663caff249 + ---> 5a6ca53c00de +Step 6/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go get github.com/kellydunn/golang-geo + ---> Running in 05b09ee0c206 +Removing intermediate container 05b09ee0c206 + ---> e68c6e222e51 +Step 7/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go + ---> Running in ea6d2707e35f +qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +The command '/bin/sh -c env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go' returned a non-zero code: 139 +make: *** [build] Error 139 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1836 b/results/classifier/deepseek-2/output/hypervisor/1836 new file mode 100644 index 000000000..9e4aa1316 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1836 @@ -0,0 +1,2 @@ + +AIX no longer boots diff --git a/results/classifier/deepseek-2/output/hypervisor/1838277 b/results/classifier/deepseek-2/output/hypervisor/1838277 new file mode 100644 index 000000000..1b981724a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1838277 @@ -0,0 +1,22 @@ + +qemu-system-aarch64: regression in 3.1: breakpoint instructions always routed to EL_D even when current EL is higher + +Affects 3.1.0 (latest stable release) and latest commit (893dc8300c80e3dc32f31e968cf7aa0904da50c3) but did *not* affect 2.11 (qemu from bionic ubuntu LTS). + +With the following code and shell commands: + +test.s: + +.text +mov x0, #0x60000000 +msr vbar_el2, x0 +dsb sy +isb sy + +$ aarch64-none-elf-as test.s -o test.o +$ aarch64-none-elf-objcopy -S -O binary test.o test.bin +$ qemu-system-aarch64 -nographic -machine virt,virtualization=on -cpu cortex-a57 -kernel test.bin -s -S + +vbar_el2 is still 0 after the code, instead of being the expected 0x60000000. (see screenshot). + +This regression doesn't seem to happen for vbar_el1 & virtualization=off. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1838390 b/results/classifier/deepseek-2/output/hypervisor/1838390 new file mode 100644 index 000000000..214f60870 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1838390 @@ -0,0 +1,13 @@ + +vmx_write_mem: mmu_gva_to_gpa failed when using hvf + +Installed qemu 4.0.0 by homebrew, used below commands: + +1. qemu-img create -f raw arch-vm.img 100G +2. qemu-system-x86_64 -show-cursor -only-migratable -nodefaults -boot order=d -cdrom archlinux-2019.07.01-x86_64.iso -cpu host -device virtio-keyboard -device virtio-mouse -device virtio-tablet -drive file=arch-vm.img,format=raw,if=virtio -m 4096 -machine q35,accel=hvf,vmport=off -nic user,ipv6=off,model=virtio -smp 4,sockets=1,cores=2,threads=2 -soundhw hda -vga virtio + +Displayed bootloader menu successfully, select "Boot Arch Linux" then crashed with message: vmx_write_mem: mmu_gva_to_gpa ffff91953b540000 failed. + +Use tcg accelerator has no problem but very slow. + +See attachment for full crash report. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1838465 b/results/classifier/deepseek-2/output/hypervisor/1838465 new file mode 100644 index 000000000..3c970a626 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1838465 @@ -0,0 +1,10 @@ + +qemu-system-x86_64 kernel panic 30% of the time starting up VM + +I have created a Fedora Core 5 x86_64 VM image. When I run the image using QEMU on Windows the VM hangs while loading the kernel about 30% of the time. I am trying to use this VM with a CI software, looking at the history the build failed 27 out of 79 attempts. QEMU 3.0.0 is installed on the CI machine. I have tried using the exact same image using QEMU on Linux (Ubuntu) and found the image boot successful every time (40+ attempts). The VM image is fairly old it was created using QEMU 0.11.1. + +I have tried multiple versions on QEMU on windows; 0.11.1, 2.12.1, and 3.0.0 all of them fail randomly. I can reproduce the issue on several different Windows 10 computers. + +The command I am using to start the VM is “qemu-system-x86_64.exe -cpu qemu64 -smp cores=2 -device e1000,netdev=net0 -boot menu=off -m 1G -drive `"file=C:\qimages\Fedora-Core-5-x64.qcow2,index=0,media=disk`" -snapshot -netdev user,id=net0,hostfwd=tcp::10022-:22” + +I can provide the qcow image but it is somewhat large coming it at 4.15GB so I’m not sure what would be the best way to transfer it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1838913 b/results/classifier/deepseek-2/output/hypervisor/1838913 new file mode 100644 index 000000000..6ce7c83f9 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1839428 b/results/classifier/deepseek-2/output/hypervisor/1839428 new file mode 100644 index 000000000..f16545d4c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1839428 @@ -0,0 +1,39 @@ + + qemu core dumped when repeat "system_reset" multiple times during guest boot + +commit 864ab314f1d924129d06ac7b571f105a2b76a4b2 (HEAD, tag: v4.1.0-rc4, origin/master, origin/HEAD, master) +Test arch:x86 and power + +Steps: +1.Boot up guest with command +power cmdline: +/usr/libexec/backup/qemu-kvm \ + -smp 8 \ + -m 4096 \ + -nodefaults \ + -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x7 \ + -drive file=rhel77-ppc64le-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none \ + -chardev stdio,mux=on,id=serial_id_serial0,server,nowait,signal=off \ + -device spapr-vty,id=serial111,chardev=serial_id_serial0 \ + -mon chardev=serial_id_serial0,mode=readline \ +x86 cmdline: +/usr/libexec/qemu-kvm \ + -m 4096 -smp 8 \ + -boot menu=on \ + -device virtio-blk-pci,id=image1,drive=drive_image1\ + -drive file=rhel77-64-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none \ + -vga std \ + -vnc :9 \ + -nographic \ + -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:84 \ + -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \ + +2.when guest start to boot up kernel(when no output infomation),run hmp command "system_reset" + + +Result: + +Sometimes,qemu core dumped with error as following: +system_reset +(qemu) qemu-system-ppc64: /root/qemu/hw/virtio/virtio.c:225: vring_get_region_caches: Assertion `caches != NULL' failed. +b.sh: line 11: 73679 Aborted (core dumped) /usr/local/bin/qemu-system-ppc64 -enable-kvm -smp 8 -m 4096 -nodefaults -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x7 -drive file=rhel77-ppc64le-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none -chardev stdio,mux=on,id=serial_id_serial0,server,nowait,signal=off -device spapr-vty,id=serial111,chardev=serial_id_serial0 -mon chardev=serial_id_serial0,mode=readline \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1841491 b/results/classifier/deepseek-2/output/hypervisor/1841491 new file mode 100644 index 000000000..2d7f776b0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1841491 @@ -0,0 +1,36 @@ + +floating point emulation can fail to set FE_UNDERFLOW + +Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. + +This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. + +On ppc64le native: +-- +$ gcc -c -O2 fma.c +$ gcc -O2 test-fma.c fma.o -lm -o test-fma +$ ./test-fma $(./test-fma) +fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022) +0x0 + +0xa000000 +FE_INEXACT FE_UNDERFLOW +0x1p-1022 +-- + +On qemu-system-ppc64: +-- +$ ./test-fma $(./test-fma) +fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022) +0x0 + +0x2000000 +FE_INEXACT +0x1p-1022 +-- + +QEMU versions vary, but not too much, and are pretty close to git HEAD: +- 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging +- 864ab31 Update version for v4.1.0-rc4 release + +There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1843254 b/results/classifier/deepseek-2/output/hypervisor/1843254 new file mode 100644 index 000000000..2fac22adb --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1843795 b/results/classifier/deepseek-2/output/hypervisor/1843795 new file mode 100644 index 000000000..4f1078ee9 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1843795 @@ -0,0 +1,32 @@ + +'mtfsf' instruction can clear FI incorrectly + +Using mtfsf instruction can clear the FPSCR FI bit incorrectly. This code snippet exhibits the issue: +-- + fpscr.ll = 0x1fffffff; + __builtin_mtfsf (0b11111111, fpscr.d); + fpscr.d = __builtin_mffs (); +-- + +On POWER9 hardware: +mffs : FPSCR = 0x000000007ffff7ff + +On qemu (git master; "-cpu POWER9"): +-- +$ ./mtfsf +mffs : FPSCR = 0x000000007ffdffff +-- + +Two differences: +bit 52: "reserved", so maybe a "don't care" case +bit 46: "FI" + +$ git log -1 master +commit 89ea03a7dc83ca36b670ba7f787802791fcb04b1 +Merge: 019217c 2531164 +Author: Peter Maydell <email address hidden> +Date: Mon Sep 9 09:48:34 2019 +0100 + +I tracked the clear is coming from do_float_check_status, likely the one in gen_mtfsf, but then I get lost figuring out what _should_ be happening. :-/ + +Test attached. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1843941 b/results/classifier/deepseek-2/output/hypervisor/1843941 new file mode 100644 index 000000000..66343a972 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1844946 b/results/classifier/deepseek-2/output/hypervisor/1844946 new file mode 100644 index 000000000..0f6604675 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1846 b/results/classifier/deepseek-2/output/hypervisor/1846 new file mode 100644 index 000000000..f307705e8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1846 @@ -0,0 +1,26 @@ + +Regression in q35 avocado tests due to fix for misaligned IO access +Description of problem: +Generally I'm seeing intermittent hangs, somewhere after the clock initialisation. + +``` +[ 4.137020] ALSA device list: +[ 4.137861] No soundcards found. +[ 4.634128] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 +[ 24.085574] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: +[ 24.085712] rcu: 0-...!: (0 ticks this GP) idle=4d18/0/0x0 softirq=54/54 fqs=0 (false positive?) +[ 24.085712] (detected by 1, t=21004 jiffies, g=-1003, q=2151 ncpus=2) +[ 24.085712] Sending NMI from CPU 1 to CPUs 0: +[ 4.647507] NMI backtrace for cpu 0 +[ 4.647507] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.11 #5 +[ 4.647507] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 +[ 4.647507] RIP: 0010:amd_e400_idle+0x39/0x40 +[ 4.647507] Code: 00 e8 fb ab 0d 00 eb 07 0f 00 2d c2 7d 1d 01 fb f4 fa 31 ff e8 e8 ab 0d 00 fb c3 cc cc cc cc eb 07 0f 00 2d a9 7d 1d 01 fb f4 <c3> cc cc cc cc 66 90 bf +01 00 00 00 e8 a6 e4 06 00 65 48 8b 04 25 +``` + +In avocado the hang generally times out and the test fails. +Steps to reproduce: +See above command line. It's racy. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1846816 b/results/classifier/deepseek-2/output/hypervisor/1846816 new file mode 100644 index 000000000..db9383d92 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1846816 @@ -0,0 +1,120 @@ + +Booting error on AIX 6.1 "Illegal Trap Instruction Interrupt in Kernel"" + +# ls -ltr +total 8750584 +-rw-rw-r-- 1 linux linux 4274997248 Oct 4 18:33 AIX.vol1.iso +-rw-rw-r-- 1 linux linux 4293888000 Oct 4 18:45 AIX.vol2.iso +-rw-rw-r-- 1 linux linux 391485440 Oct 4 18:50 AIX.vol3.iso +-rw-r--r-- 1 root root 204608 Oct 4 19:00 AIX61.img + +# qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8192 -serial mon:stdio \ +> -drive file=/qemu/BST/AIX61.img,if=none,id=drive-virtio-disk0 \ +> -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ +> -cdrom /qemu/BST/AIX.vol1.iso \ +> -prom-env boot-command='boot cdrom: -s verbose' + + +VNC server running on ::1:5900 +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 3 2019 12:26:14 + FW Version = git-ba1ab360eebe6338 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: -s verbose from: /vdevice/v-scsi@71000003/disk@8200000000000000: ... Successfully loaded +qemu-system-ppc64: Couldn't negotiate a suitable PVR during CAS +AIX +StarLED{814} + +AIX Version 6.1 +exec(/etc/init){1,0} + +INIT: EXECUTING /sbin/rc.boot 1 +exec(/usr/bin/sh,-c,/sbin/rc.boot 1){1114146,1} +exec(/sbin/rc.boot,/sbin/rc.boot,1){1114146,1} ++ PHASE=1 ++ + bootinfo -p +exec(/usr/sbin/bootinfo,-p){1179684,1114146} +PLATFORM=chrp ++ [ ! -x /usr/lib/boot/bin/bootinfo_chrp ] ++ [ 1 -eq 1 ] ++ 1> /usr/lib/libc.a ++ init -c unlink /usr/lib/boot/bin/!(*_chrp) +exec(/etc/init,-c,unlink /usr/lib/boot/bin/!(*_chrp)){1179686,1114146} ++ chramfs -t +exec(/usr/sbin/chramfs,-t){1179688,1114146} ++ init -c unlink /usr/sbin/chramfs ++ 1> /dev/null +exec(/etc/init,-c,unlink /usr/sbin/chramfs){1179690,1114146} ++ + bootinfo -t +exec(/usr/sbin/bootinfo,-t){1179692,1114146} +BOOTYPE=3 ++ [ 0 -ne 0 ] ++ [ -z 3 ] ++ unset pdev_to_ldev undolt native_netboot_cfg ++ unset disknet_odm_init config_ATM ++ /usr/lib/methods/showled 0x510 DEV CFG 1 START +exec(/usr/lib/methods/showled,0x510,DEV CFG 1 START){1179694,1114146} ++ cfgmgr -f -v +exec(/usr/sbin/cfgmgr,-f,-v){1179696,1114146} +cfgmgr is running in phase 1 +---------------- +Time: 0 LEDS: 0x538 +Invoking top level program -- "/etc/methods/defsys" +exec(/bin/sh,-c,/etc/methods/defsys ){1245222,1179696} +exec(/etc/methods/defsys){1245222,1179696} +exec(/bin/sh,-c,/usr/lib/methods/define_rspc -n -c sys -s node -t chrp){1310760,1245222} +exec(/usr/lib/methods/define_rspc,-n,-c,sys,-s,node,-t,chrp){1310760,1245222} +Time: 0 LEDS: 0x539 +Return code = 0 +***** stdout ***** +sys0 + +*** no stderr **** +---------------- +Attempting to configure device 'sys0' +Time: 0 LEDS: 0x811 +Invoking /usr/lib/methods/cfgsys_chrp -1 -l sys0 +exec(/bin/sh,-c,/usr/lib/methods/cfgsys_chrp -1 -l sys0){1245224,1179696} +Number of running methods: 1 +exec(/usr/lib/methods/cfgsys_chrp,-1,-l,sys0){1245224,1179696} +LED{A20} +Illegal Trap Instruction Interrupt in Kernel +04151A74 tweqi r0,0 r0=0 +KDB(0)> \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1850378 b/results/classifier/deepseek-2/output/hypervisor/1850378 new file mode 100644 index 000000000..7090b12e0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1850378 @@ -0,0 +1,19 @@ + +RISC-V unreliable IPIs + +I am working on a project with custom inter processor interrupts (IPIs) on the RISC-V virt machine. +After upgrading from version 3.1.0 to 4.1.0 which fixes a related issue (https://github.com/riscv/riscv-qemu/issues/132) I am able to use the CPU hotplug feature. + +However, if I try to use IPIs for communication between two cores, the wfi instruction behaves strangely. Either it does not return, or it returns on timer interrupts, even though they are disabled. The code, I use on one core to wait for an interrupt is the following. + + csr_clear(sie, SIE_SEIE | SIE_STIE); + do { + wait_for_interrupt(); + sipval = csr_read(sip); + sieval = csr_read(sie); + scauseval = csr_read(scause) & 0xFF; + /* only break if wfi returns for an software interrupt */ + } while ((sipval & sieval) == 0 && scauseval != 1); + csr_set(sie, SIE_SEIE | SIE_STIE); + +Since the resulting sequence does not seem to be deterministic, my guess is, that it has something to do with the communication of qemu's threads for the different cores. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1851845 b/results/classifier/deepseek-2/output/hypervisor/1851845 new file mode 100644 index 000000000..8b844452e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1851845 @@ -0,0 +1,13 @@ + +Windows 10 panics with BlueIris + +Running Windows 10 64bit. Starting BlueIris 64 bit causes Windows to panic with CPU type is set higher than Penryn or CPU type = host. + +I have been able to reproduce the same issue on Proxmox 4,5,6 as well as oVirt 3. and 4. + +Does not panic when CPU type is set to kvm64. + + +pve-qemu-kvm/stable 4.0.1-4 amd64 + + /usr/bin/kvm -id 102 -name win7-01 -chardev socket,id=qmp,path=/var/run/qemu-server/102.qmp,server,nowait -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/102.pid -daemonize -smbios type=1,uuid=3ec61114-c30c-4719-aa00-f3f05be22d48 -smp 8,sockets=1,cores=8,maxcpus=8 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vnc unix:/var/run/qemu-server/102.vnc,password -no-hpet -cpu penryn,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer,hv_ipi,enforce -m 12000 -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device vmgenid,guid=50deb929-1974-4fd0-9ad3-71722149d568 -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=tablet,bus=uhci.0,port=1 -device VGA,id=vga,bus=pci.0,addr=0x2 -chardev socket,path=/var/run/qemu-server/102.qga,server,nowait,id=qga0 -device virtio-serial,id=qga0,bus=pci.0,addr=0x8 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-name=iqn.1993-08.org.debian:01:203582cea152 -drive if=none,id=drive-ide2,media=cdrom,aio=threads -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -drive file=/disk02/prox/images/102/vm-102-disk-0.raw,if=none,id=drive-virtio0,cache=writeback,format=raw,aio=threads,detect-zeroes=on -device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 -drive file=/dev/disk/by-id/ata-WDC_WD80EMAZ-00WJTA0_7SGZLHYC-part1,if=none,id=drive-virtio1,cache=writeback,format=raw,aio=threads,detect-zeroes=on -device virtio-blk-pci,drive=drive-virtio1,id=virtio1,bus=pci.0,addr=0xb -netdev type=tap,id=net0,ifname=tap102i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=1e:be:cb:0b:6f:13,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 -netdev type=tap,id=net1,ifname=tap102i1,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=EA:76:56:16:2F:D7,netdev=net1,bus=pci.0,addr=0x13,id=net1,bootindex=301 -rtc driftfix=slew,base=localtime -machine type=pc -global kvm-pit.lost_tick_policy=discard \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1853429 b/results/classifier/deepseek-2/output/hypervisor/1853429 new file mode 100644 index 000000000..c503008ec --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1853429 @@ -0,0 +1,9 @@ + +qemu-kvm on aarch64 attach volume failed when vm is booting + +I use libvirt and qemu-kvm on aarch64 platform to attach volume to a booting vm，when the system of vm has not boot up, attach volume will be failed, after vm system booting up, attach volume can be successful. + +libvirt: 4.5.0 +qemu : 2.12.0 + +console log and qemu command of vm is in attachment. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1855072 b/results/classifier/deepseek-2/output/hypervisor/1855072 new file mode 100644 index 000000000..63b2a840e --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1855617 b/results/classifier/deepseek-2/output/hypervisor/1855617 new file mode 100644 index 000000000..97f91b8f9 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1856335 b/results/classifier/deepseek-2/output/hypervisor/1856335 new file mode 100644 index 000000000..525d3b205 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1861 b/results/classifier/deepseek-2/output/hypervisor/1861 new file mode 100644 index 000000000..220583d57 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1861 @@ -0,0 +1,30 @@ + +qemu 8.1.0 fails to build with ppc64l and musl libc +Description of problem: +qemu 8.1.0 fails to build on alpine linux ppc64le: + +``` +ninja: job failed: gcc -m64 -mlittle-endian -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -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 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -isystem /home/ncopa/aports/community/qemu/src/qemu-8.1.0/linux-headers -isystem linux-headers -iquote . -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0 -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/include -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/host/include/ppc64 -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/host/include/generic -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/tcg/ppc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -Os -fstack-clash-protection -Wformat -Werror=format-security -O2 -fPIE -pthread -MD -MQ libqemuutil.a.p/util_cpuinfo-ppc.c.o -MF libqemuutil.a.p/util_cpuinfo-ppc.c.o.d -o libqemuutil.a.p/util_cpuinfo-ppc.c.o -c ../util/cpuinfo-ppc.c +../util/cpuinfo-ppc.c: In function 'cpuinfo_init': +../util/cpuinfo-ppc.c:33:18: error: 'PPC_FEATURE2_ARCH_3_1' undeclared (first use in this function); did you mean 'PPC_FEATURE2_ARCH_3_00'? + 33 | if (hwcap2 & PPC_FEATURE2_ARCH_3_1) { + | ^~~~~~~~~~~~~~~~~~~~~ + | PPC_FEATURE2_ARCH_3_00 +../util/cpuinfo-ppc.c:33:18: note: each undeclared identifier is reported only once for each function it appears in +../util/cpuinfo-ppc.c:43:18: error: 'PPC_FEATURE2_HAS_ISEL' undeclared (first use in this function); did you mean 'PPC_FEATURE_HAS_VSX'? + 43 | if (hwcap2 & PPC_FEATURE2_HAS_ISEL) { + | ^~~~~~~~~~~~~~~~~~~~~ + | PPC_FEATURE_HAS_VSX +../util/cpuinfo-ppc.c:56:26: error: 'PPC_FEATURE2_HAS_VEC_CRYPTO' undeclared (first use in this function); did you mean 'PPC_FEATURE2_VEC_CRYPTO'? + 56 | if (hwcap2 & PPC_FEATURE2_HAS_VEC_CRYPTO) { + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + | PPC_FEATURE2_VEC_CRYPTO +ninja: subcommand failed +make: *** [Makefile:162: run-ninja] Error 1 +``` +Steps to reproduce: +Build qemu 8.1.0 on alpine linux ppc64le. +Additional information: +Likely introduced by 623d7e3551a6fc5693c06ea938c60fe281b52e27 + +Explicit `#include <asm/cputable.h>` fixes the `PPC_FEATURE2_ARCH_3_1` case but not the other two. diff --git a/results/classifier/deepseek-2/output/hypervisor/1861394 b/results/classifier/deepseek-2/output/hypervisor/1861394 new file mode 100644 index 000000000..b2cfa3505 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1861394 @@ -0,0 +1,15 @@ + +qemu-system-riscv64 hangs after poweroff linux command + +QEMU Version : v4.2.0-773-g43d1455-dirty (commit 43d1455cf84283466e5c22a217db5ef4b8197b14) + +Command: qemu-system-riscv64 -machine virt -kernel ./bbl -nographic -initrd rootfs.cpio.gz -append "root=/dev/ram console=ttyS0" + +Host:LSB Version: :core-4.1-amd64:core-4.1-noarch +Distributor ID: CentOS +Description: CentOS Linux release 7.7.1908 (Core) +Release: 7.7.1908 +Codename: Core + + +Problem: after boot, when type poweroff -f it hangs (not quitting). I have tested this for x86_64, and aarch64 and it works fine. The problem appears only for risv64(of those mentioned). Last time i have checked it worked also for riscv64 and it was on the d0f90e1423b4f412adc620eee93e8bfef8af4117 commit \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1861653 b/results/classifier/deepseek-2/output/hypervisor/1861653 new file mode 100644 index 000000000..ae419b01e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1861653 @@ -0,0 +1,37 @@ + +CPU of qemu-system-aarch64 always stuck + +I started qemu with these arguments: + qemu-system-aarch64 -M virt-2.9 -cpu cortex-a72 -smp cores=8,threads=1,sockets=1 -m 2G -device nec-usb-xhci -device usb-kbd -device usb-tablet -pflash /sdcard/QEMU_EFI.img -pflash /sdcard/QEMU_VARS.img -device virtio-blk-device,drive=Ubuntu -drive if=none,id=Ubuntu,file=Ubuntu.vhd -nographic -net user -net nic,model=rtl8139 -kernel linux -initrd initrd.gz +The setup program of Ubuntu devel aarch64 ran normally.But after several hours,the CPUs emulated by qemu-system-aarch64 went wrong. +Here are the messages displayed on the tty +[15842.164745] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] [15930.163589] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] +[16110.163540] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] +[16290.162801] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] +[16470.163927] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] +[16650.163246] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] +[16830.163216] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] +[17010.164504] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] + +Then I tried CentOS 7.1908 aarch64 with almost the same arguments. +After several hours,it went wrong too. +[17480 . 201 1 58] rcu : (3 ticks this GP) idle=362/0/0x3 softirq=61631 /61 631 fqs=10077 +[17480 . 204889] (detected by 3 , t=24007 jiffies , g=218453 , q=5285) [1 7480 . 21 7986] Task dump for CPU 7 : +[17480.222379] swapper/7R running task 0 +0 0x0000002a [17480.229073] Call trace : +[1 7480.241518] switch t0+0x104/0x1 f8 +[17480.249839] Ox7fffffffffffffff +[17660.232314] rcu : INFO: rcu sched detected stalls on CPUs/ tasks : +[17660.233580] rcu : (3 ticks this GP) idle=362/0/0x3 softirq=61631 /61 631 fqs=17770 +[17660.235837] (detected by 3,t=42012 jiffies , g=218453 , q=7039) +[17660 . 237955] Task dump for CPU 7 : +[17660.238900] swapper/ 7 R running task 0 0 +[17660.242967] Call trace : +[17660.246192] switch t0+0x104/0x1 f8 +[17660.253215] Ox7fffffffffffffff + +Obviously qemu-system-aarch64 caused these bugs. + +qemu version: 4.x(I have tested version 4.0 & 4.1.0 & 4.2.0) +host architecture: aarch64(Qualcomm Snapdragon series) +host system:Ubuntu devel 20.04& Debian 10(I have tested on many devices) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1863200 b/results/classifier/deepseek-2/output/hypervisor/1863200 new file mode 100644 index 000000000..f8e2fe8ad --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1863200 @@ -0,0 +1,71 @@ + +Reconnect failed with loopback virtio1.1 server mode test + +Issue discription： +Packed ring server mode is a new feature to enable the virtio-user or virtio-pmd(in VM) as the server, vhost as the client, then when the vhost-user is killed then re-launched, the vhost-user can connect back to virtio-user/virtio-pmd again. Test with dpdk 20.02 ,virtio-pmd loopback reconnect from vhost-user failed. + +Test Environment: +DPDK version: DPDK v20.02 +Other software versions: virtio1.1 +Qemu versions:4.2.0 +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 +Hardware platform: R2208WFTZSR. + +The reproduce step is : +Test Case: vhost-user/virtio-pmd loopback reconnect from vhost-user +=============================================================== +Flow: Vhost-user --> Virtio --> Vhost-user + +1. Launch vhost-user with client mode by below commands:: + + ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1 + testpmd>set fwd mac + +2. Start VM with 1 virtio device, and set the qemu as server mode:: + + ./qemu-system-x86_64 -name vm2 -enable-kvm -cpu host -smp 100 -m 8G \ + -object memory-backend-file,id=mem,size=8192M,mem-path=/mnt/huge,share=on \ + -numa node,memdev=mem -mem-prealloc -drive file=/home/xuan/dpdk_project/shell/u18.img \ + -chardev socket,path=/tmp/vm2_qga0.sock,server,nowait,id=vm2_qga0 -device virtio-serial \ + -device virtserialport,chardev=vm2_qga0,name=org.qemu.guest_agent.2 -daemonize \ + -monitor unix:/tmp/vm2_monitor.sock,server,nowait -net nic,macaddr=00:00:00:08:e8:aa,addr=1f \ + -net user,hostfwd=tcp:127.0.0.1:6002-:22 \ + -chardev socket,id=char0,path=/tmp/vhost-net,server \ + -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce \ + -device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,mrg_rxbuf=on,rx_queue_size=1024,tx_queue_size=1024,packed=on \ + -vnc :10 + +3. On VM, bind virtio net to igb_uio and run testpmd:: + + ./testpmd -c 0x3 -n 4 -- -i --nb-cores=1 --txd=1024 --rxd=1024 + testpmd>set fwd mac + testpmd>start + +4. Send packets by vhost-user, check if packets can be RX/TX with virtio-pmd:: + + testpmd>start tx_first 32 + testpmd>show port stats all + +5. On host, quit vhost-user, then re-launch the vhost-user with below command:: + + testpmd>quit + ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1 + testpmd>set fwd mac + testpmd>start tx_first 32 + +6. Check if the reconnection can work, still send packets by vhost-user, check if packets can be RX/TX with virtio-pmd:: + + testpmd>show port stats all + +Expected result:: + +After the vhost-user is killed then re-launched, the VM can connect back to vhost-user again with throughput. + +Real result:: + +After the vhost-user is killed then re-launched, no throughput with PVP. + +Analysis:: + +QEMU has its own way to handle reconnect function for virtio server mode. However, for packed ring, when reconnecting to virtio, vhost cannot get the status of descriptors via the descriptor ring. This bug is caused since the reconnection for packed ring need additional reset operation. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1863685 b/results/classifier/deepseek-2/output/hypervisor/1863685 new file mode 100644 index 000000000..b399ca7db --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1863685 @@ -0,0 +1,9 @@ + +ARM: HCR.TSW traps are not implemented + +On 32-bit and 64-bit ARM platforms, setting HCR.TSW is supposed to "Trap data or unified cache maintenance instructions that operate by Set/Way." Quoting the ARM manual: + +If EL1 is using AArch64 state, accesses to DC ISW, DC CSW, DC CISW are trapped to EL2, reported using EC syndrome value 0x18. +If EL1 is using AArch32 state, accesses to DCISW, DCCSW, DCCISW are trapped to EL2, reported using EC syndrome value 0x03. + +However, QEMU does not trap those instructions/registers. This was tested on the branch master of the git repo. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1864 b/results/classifier/deepseek-2/output/hypervisor/1864 new file mode 100644 index 000000000..804fbd687 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1864 @@ -0,0 +1,22 @@ + +x86 VM with TCG and SMP fails to start on 8.1.0 +Description of problem: +I'm running Colima on MacOS to run Docker. After upgrading qemu to 8.1.0 my x86_64 VM fails to start. If I downgrade qemu to 8.0.4 everything runs normally. Relevant logs: + +``` +[ 60.976187] rcu: 0-...!: (0 ticks this GP) idle=0d58/0/0x0 softirq=44/44 fqs=0 (false positive?) +[ 60.979262] (detected by 1, t=6005 jiffies, g=-1171, q=1981 ncpus=2) +[ 60.982317] Sending NMI from CPU 1 to CPUs 0: +[ 11.583693] NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0xb/0x10 +[ 11.583693] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 2.006 msecs +[ 60.982317] rcu: rcu_preempt kthread timer wakeup didn't happen for 6004 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 +[ 60.982317] rcu: Possible timer handling issue on cpu=0 timer-softirq=15 +[ 60.982317] rcu: rcu_preempt kthread starved for 6005 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0 +[ 60.982317] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. +[ 60.982317] rcu: RCU grace-period kthread stack dump: +[ 60.982317] task:rcu_preempt state:I stack:0 pid:15 ppid:2 flags:0x00004000 +``` + +[serial.log](/uploads/1039eceff37133504eb93401df1db137/serial.log) +Steps to reproduce: +1. `colima start --arch x86_64` diff --git a/results/classifier/deepseek-2/output/hypervisor/1864536 b/results/classifier/deepseek-2/output/hypervisor/1864536 new file mode 100644 index 000000000..7dea9ba38 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1864536 @@ -0,0 +1,27 @@ + +Support for XSAVES intel instructions in QEMU + +Dear QEMU developers, + +I am running Hyper-V on qemu+kvm. During it initialization, it checks for XSAVES support: first it executes CPUID with EAX = 0xd and ECX = 1 and looks at bit 3 in the returned value of EAX (Supports XSAVES/XRSTORS and IA32_XSS [1]), and then it reads the MSR IA32_VMX_PROCBASED_CTLS2 (index 0x48B) and looks at bit 20 (Enable XSAVES/XSTORS [2]). If CPUID shows that XSAVES is supported and the bit is not enabled in the MSR, Hyper-V decides to fail and stops its initialization. It used to work until last spring/summer where something might have changed in either KVM or QEMU. + +It seems that KVM sets the correct flags (in CPUID and the MSR) when the host CPU supports XSAVES. In QEMU, based on comments in target/i386/cpu.c it seems that XSAVES is not added in +builtin_x86_defs[].features[FEAT_VMX_SECONDARY_CTLS] because it might break live migration. Therefore, when setting the MSR for the vcpu, QEMU is masking off the feature. + +I have tested two possible solutions: +- adding the flag in .features[FEAT_VMX_SECONDARY_CTLS] +- removing the support of the instruction in feature_word_info[FEAT_XSAVE].feat_names + +Both solutions work and Hyper-v is happily running. I can provide a patch for the solution you might consider applying. Otherwise, is there a better way to fix the issue? + +Qemu version: 4.2.0 +Kernel version: 5.5.4 +Qemu command: https://gist.github.com/0xabe-io/b4d797538e2160252addc1d1d64738e2 + + +Many thanks, +Alexandre + +Ref: +[1] Intel SDM Volume 2A, chapter 3, page 196 +[2] Intel SDM Volume 3C, chapter 24, page 11 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1867072 b/results/classifier/deepseek-2/output/hypervisor/1867072 new file mode 100644 index 000000000..3c81a4556 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1867072 @@ -0,0 +1,10 @@ + +ARM: tag bits cleared in FAR_EL1 + +The ARM Architecture Reference Manual provides the following for FAR_EL1: + +"For a Data Abort or Watchpoint exception, if address tagging is enabled for the address accessed by the data access that caused the exception, then this field includes the tag." + +However, I have found that the tag bits in FAR_EL1 are always clear, even if the tag bits were set in the original access. + +I can reproduce the problem on both 4.1.1 and master (6e8a73e911f066527e775e04b98f31ebd19db600). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1868527 b/results/classifier/deepseek-2/output/hypervisor/1868527 new file mode 100644 index 000000000..bdce419c7 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1869858 b/results/classifier/deepseek-2/output/hypervisor/1869858 new file mode 100644 index 000000000..7704db707 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1869858 @@ -0,0 +1,7 @@ + +qemu can't start Windows10arm64 19H1(with kvm) + +My cpu's model is arm64(cortex-a53),I want start Win10arm64 with kvm,Because is fast than x86.But it's did'nt work.The screnn is card in Uefi's logo. But I am use ramfb now,So it has nothing to do with the graphics card.But if I discard kvm,It can start now.But its so slowly.But I use the uefi and kvm can start with Debian arm64 buster. So who's the problem?qemu or kvm or Microsoft?But others use it to start successfully. I don't know what I would like to do +This is start command(Qemu version is 4.1') +qemu-system-aarch64 -hda /win10.vhdx -cdrom /win10arm.iso -m 1G -accel kvm -smp 4 -cpu host -pflash efi.img -pflash var.img -device ramfb -device qemu-xhci -device usb-kbd -device usb-mouse -device usb-tablet +If I replace the above three parameters with "- CPU cortex-a53" and "- accel TCG" and "- device VGA", I can start normally. What's the matter? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1871250 b/results/classifier/deepseek-2/output/hypervisor/1871250 new file mode 100644 index 000000000..6b999024f --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1871842 b/results/classifier/deepseek-2/output/hypervisor/1871842 new file mode 100644 index 000000000..043af99e9 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1871842 @@ -0,0 +1,52 @@ + +AMD CPUID leaf 0x8000'0008 reported number of cores inconsistent with ACPI.MADT + +Setup: +CPU: AMD EPYC-v2 or host's EPYC cpu +Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 +qemu version: self build +git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 +config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' + +Cmdline: +qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 + +Issue: +We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. +In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] + +The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 +The lower four bits of ECX are the [NC] field and all set. + +When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 +Note, ECX is zero. Indicating that this is no SMP capabale CPU. + +I'm debugging it using my local machine and the QEMU provided EPYC-v2 CPU model and it is reproducible there as well and reports: EAX: 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 + +I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. +I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. + +The following table shows my findings with the -smp option: +Option | Qemu guest observed ECX value +-smp 4 | 0x0 +-smp 4,cores=4 | 0x3 +-smp 4,cores=2,thread=2 | 0x3 +-smp 4,cores=4,threads=2 | QEMU boot error: topology false. + +Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. +Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? + +Querying 0x8000'0008 on the physical processor results in different reports than quering QEMU's model as does it with -enable-kvm -cpu host. + +Furthermore, the ACPI.MADT shows 4 local APICs to be present while the CPU leave reports a single core processor. + +This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the wrong number. + + +Please let me know, if you need more information from my side. + + +[0] https://github.com/kernkonzept/fiasco/blob/522ccc5f29ab120213cf02d71328e2b879cbbd19/src/kern/ia32/kernel_thread-ia32.cpp#L109 +[1] https://github.com/kernkonzept/fiasco/blob/522ccc5f29ab120213cf02d71328e2b879cbbd19/src/kern/ia32/cpu-ia32.cpp#L1120 +[2] https://github.com/qemu/qemu/blob/f2a8261110c32c4dccd84e774d8dd7a0524e00fb/target/i386/cpu.c#L5835 +[3] https://www.amd.com/system/files/TechDocs/24594.pdf \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1872790 b/results/classifier/deepseek-2/output/hypervisor/1872790 new file mode 100644 index 000000000..9400b89ae --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1872790 @@ -0,0 +1,10 @@ + +empty qcow2 + +I plugged multiple qcow2 to a Windows guest. On the Windows disk manager all disks are listed perfectly, with their data, their real space, I even can explore all files on the Explorer, all cool + +On third party disk manager (all of them), I only have the C:\ HDD who act normally, all the other plugged qcow2 are seen as fully unallocated, so I can't manipulate them + +I want to move some partitions, create others, but on Windows disk manager I can't extend or create partition and on third party I didn't see the partitions at all + +Even guestfs doesn't recognize any partition table `libguestfs: error: inspect_os: /dev/sda: not a partitioned device` \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1873340 b/results/classifier/deepseek-2/output/hypervisor/1873340 new file mode 100644 index 000000000..1ed530ff9 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1873340 @@ -0,0 +1,18 @@ + +KVM Old ATI(pre) AMD card passthrough is not working + +Hello, +tried to passthroug old ATI pre AMD PCI / PCI-E cards, on machine where anything else is working - Nvidia /Matrox / 3dfx cards.. + +Here are results: +ATI Mach 64 PCI - videocard - machine start segfault +ATI Rage XL PCI - videocard - machine start segfault +ATI Radeon 7000 PCI - Segmentation fault +ATI X600 Giabyte GV-RX60P128D - Segmentation fault +ATI X700 PCI-E Legend - videocard - completely broken picture from boot +ATI X800 XL PCI-E Gigabyte - videocard - completely broken picture from boot + All cards has last bioses. + +ATI X600 - HP one professional with DMS-59 connector, im unable to make passthrough, but im not able to set in Windows 98/WinXP machine.. anything less than 16 bit colors.. Im getting VM crashes or boot freezes, when i try to boot with more colors. + + Qemu 2.11 and 4.2, is the same, Mint Linux 19.3. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1873344 b/results/classifier/deepseek-2/output/hypervisor/1873344 new file mode 100644 index 000000000..a183ff2e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1873344 @@ -0,0 +1,13 @@ + +KVM Windows 98 sound card passthrough is not working for DOS programs.. + +Hello, +im trying to passthrough PCI soundcards into Qemu Windows 98 machine - i tried Yamaha 724/744 and Aunreal Vortex 1, for Windows 98 its working fine, but for Windows 98 dosbox mode its at the best half - working - FM (music) only or nothing with detected by games sound setups. + All there cards are using SB emulation devices. + + When i try to boot to pure DOS, without Windows 98, even music is not working with pass through, only sound which i was able to heard its form Yamaha Setup utility test - Native 16bit sound, aby other test, games setup etc.. are able to dettect sound cards at all. + Im pretty sure that drivers are setup correctly, because im using same setup on other physical machine, when its working. My suspect is missing or broken Qemu MB DMA channels emulation.. Because its is need to make DOS sound working. + + Im using pass through because, SB16 emulation in Qemu is incomplete and for Windows 98 dos box, problem is same as with physical cards. Same with AC97 emulation and its Win95 drivers, which have SB emulation device fallback.. + +Qemu 2.11 + 4.2 Linux Mint 19.3. MB Gigabyte Z170. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1873542 b/results/classifier/deepseek-2/output/hypervisor/1873542 new file mode 100644 index 000000000..8934390ea --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1873542 @@ -0,0 +1,14 @@ + +Windows 98 videocard passthrough - unable to load higher resolution -Desktop, after some games crashes, without whole physical machine reset.. + +When you are using games which are using fullscreen switching resolutions (some old games are 640x480 or 800x600 max), videocard is often stuck after crash and whole Linux machine has to be rebooted, to fix it.. VM reboot is not enough. + + That stuck is strange one, after restart of machine, text mode is working fine, but graphical mode should be set to higher resolution (Load Windows 98 desktop) there is only black screen and screen input blinking. + + I simulated it with multiple videocards, graphical drivers, its quite often, full Linux reboot is always safe it. Im using right roms for my cards, because otherwise i get often even boot machine twice in one Linux boot session. + + Some there is need for some better card reset. + + Also some videocard reset on Linux level workaround would be nice. + + Simulated on Qemu 2.11 and 4.2 and Linux Mint 19.3, but my guess its whole KVM videocard passthrough problem. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1874 b/results/classifier/deepseek-2/output/hypervisor/1874 new file mode 100644 index 000000000..3379347f6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1874 @@ -0,0 +1,18 @@ + +QGA：Whether arm windows VMS are supported？ +Description of problem: +Whether qga can be used within an arm windows virtual machine? + +Windows reports an error (Failed to pCatalog->InstallComponent.(Error: 80110401) Errors occurred accessing one or more objects - the ErrorInfo collection may have more detail) when I try to install msi. Windows reports a warning(Catalog Event ID 5488: Unable to load DLL qga-vss.dll) (Unable to validate DLL entry points) in Event Viewer. + +I get msi from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-qemu-ga/qemu-ga-win-105.0.2-1.el9/qemu-ga-x86_64.msi +Either gqa does not support ARM or this msi is only for X86 architecture? + + + + +Steps to reproduce: +1. Start arm windows 11 vm. +2. Install qemu guest agent. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/1874504 b/results/classifier/deepseek-2/output/hypervisor/1874504 new file mode 100644 index 000000000..f320a6a37 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1874504 @@ -0,0 +1,26 @@ + +VFIO passthrough spits out thousands of messages + +started qemu as: +sudo qemu-system-sparc64 -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB + +messages received thousands of times: + +qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: iommu has granularity incompatible with target AS +qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: iommu map to non memory area 4079c000 + +qemu version (think telling a lie as sure its 5.0) +QEMU emulator version 4.2.92 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +pci device being passed through: + +0b:05.0 Display controller [0380]: 3DLabs Permedia II 2D+3D [3d3d:0009] (rev 01) + Subsystem: Tech-Source Permedia II 2D+3D [1227:0006] + Flags: medium devsel, IRQ 11 + Memory at 83000000 (32-bit, non-prefetchable) [disabled] [size=128K] + Memory at 82800000 (32-bit, non-prefetchable) [disabled] [size=8M] + Memory at 82000000 (32-bit, non-prefetchable) [disabled] [size=8M] + Expansion ROM at 83020000 [disabled] [size=64K] + Capabilities: <access denied> + Kernel driver in use: vfio-pci \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1875012 b/results/classifier/deepseek-2/output/hypervisor/1875012 new file mode 100644 index 000000000..bd4b4a663 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1875012 @@ -0,0 +1,27 @@ + +UC20 running in OVMF triggers qemu emulation error (cloudimage works fine on the same) + +Trying to boot a core20 amd64 image on an amd64 Eoan or Focal host via libvirt leads to: + +KVM internal error. Suberror: 1 +emulation failure +RAX=0000000000000000 RBX=000000003bdcd5c0 RCX=000000003ff1d030 RDX=00000000000019a0 +RSI=00000000000000ff RDI=000000003bd73ee0 RBP=000000003bd73e40 RSP=000000003ff1d1f8 +R8 =000000003df52168 R9 =0000000000000000 R10=ffffffffffffffff R11=000000003bd44c40 +R12=000000003bd76500 R13=000000003bd73e00 R14=0000000000020002 R15=000000003df4b483 +RIP=00000000000b0000 RFL=00210246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0038 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 000000003fbee698 00000047 +IDT= 000000003f2d8018 00000fff +CR0=80010033 CR2=0000000000000000 CR3=000000003fc01000 CR4=00000668 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d00 +Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <ff> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1876373 b/results/classifier/deepseek-2/output/hypervisor/1876373 new file mode 100644 index 000000000..30311d262 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1876373 @@ -0,0 +1,49 @@ + +segfault mremap 4096 + +a qemu-hosted process segfaults when the program calls mremap to shrink the size of a buffer to 4096 that was allocated with mmap. See below for a C program to reproduce this issue. I was able to compile this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-arm to reproduce the segfault. If I run the i386 program natively on my x86_64 system, no segfault occurs. Also note that if I change the mremap size to something else such as 12288, no segfault occurs. I also confirmed using qemu's -singlestep debug option that the segfault occurs during the mremap syscall. + +If you save the source below to mremapbug.c, the following should reproduce the issue given you have gcc-multilib: + +gcc -m32 mremapbug.c +# works +./a.out +# segfault +qemu-i386 a.out + +If you can also compile to arm, the same thing happens when running "qemu-arm a.out". I also tried compiling natively and running "qemu-x86_64 a.out" but no segfault in that case, not sure if it's because it is 64-bits or if it was because it was my native target. + + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <sys/mman.h> + +int main(int argc, char *argv[]) +{ + const size_t initial_size = 8192; + + printf("calling mmap, size=%llu\n", (unsigned long long)initial_size); + void *mmap_ptr = mmap(NULL, initial_size, + PROT_READ | PROT_WRITE , + MAP_PRIVATE | MAP_ANONYMOUS, + -1, 0); + printf("mmap returned : %p\n", mmap_ptr); + if (mmap_ptr == MAP_FAILED) { + perror("mmap"); + exit(1); + } + + const size_t new_size = 4096; + printf("calling mremap, size=%llu\n", (unsigned long long)new_size); + void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0); + printf("mremap returned: %p\n", remap_ptr); + if (remap_ptr != mmap_ptr) { + perror("mreamap"); + exit(1); + } + printf("Success: pointers match\n"); +} + + +This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts. I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1877781 b/results/classifier/deepseek-2/output/hypervisor/1877781 new file mode 100644 index 000000000..d3b3b1a20 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1879425 b/results/classifier/deepseek-2/output/hypervisor/1879425 new file mode 100644 index 000000000..01ae23f1a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1879425 @@ -0,0 +1,34 @@ + +The thread of "CPU 0 /KVM" keeping 99.9%CPU + +Hi Expert: + +The VM is hung here after (2, or 3, or 5 and the longest time is 10 hours) by qemu-kvm. +Notes: +for VM: + OS: RHEL 7.6 + CPU: 1 + MEM:4G +For qemu-kvm: + 1) version: + /usr/libexec/qemu-kvm -version + QEMU emulator version 2.10.0(qemu-kvm-ev-2.10.0-21.el7_5.4.1) + 2) once the issue is occurred, the CPU of "CPU0 /KVM" is more than 99% by com "top -p VM_pro_ID" + PID UDER PR NI RES S % CPU %MEM TIME+ COMMAND +872067 qemu 20 0 1.6g R 99.9 0.6 37:08.87 CPU 0/KVM + 3) use "pstack 493307" and below is function trace +Thread 1 (Thread 0x7f2572e73040 (LWP 872067)): +#0 0x00007f256cad8fcf in ppoll () from /lib64/libc.so.6 +#1 0x000055ff34bdf4a9 in qemu_poll_ns () +#2 0x000055ff34be02a8 in main_loop_wait () +#3 0x000055ff348bfb1a in main () + 4) use strace "strace -tt -ff -p 872067 -o cfx" and below log keep printing +21:24:02.977833 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=80, events=POLLIN}, {fd=82, events=POLLIN}, {fd=84, events=POLLIN}, {fd=115, events=POLLIN}, {fd=121, events=POLLIN}], 9, {0, 0}, NULL, 8) = 0 (Timeout) +21:24:02.977918 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=80, events=POLLIN}, {fd=82, events=POLLIN}, {fd=84, events=POLLIN}, {fd=115, events=POLLIN}, {fd=121, events=POLLIN}], 9, {0, 911447}, NULL, 8) = 0 (Timeout) +21:24:02.978945 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=80, events=POLLIN}, {fd=82, events=POLLIN}, {fd=84, events=POLLIN}, {fd=115, events=POLLIN}, {fd=121, events=POLLIN}], 9, {0, 0}, NULL, 8) = 0 (Timeout) +Therefore, I think the thread "CPU 0/KVM" is in tight loop. + 5) use reset can recover this issue. however, it will reoccurred again. +Current work around is increase one CPU for this VM, then issue is gone. + +thanks +Cliff \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/188 b/results/classifier/deepseek-2/output/hypervisor/188 new file mode 100644 index 000000000..318936dc7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/188 @@ -0,0 +1,2 @@ + +savevm with hax saves wrong register state diff --git a/results/classifier/deepseek-2/output/hypervisor/1880507 b/results/classifier/deepseek-2/output/hypervisor/1880507 new file mode 100644 index 000000000..bfbcb5aea --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/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/deepseek-2/output/hypervisor/1880763 b/results/classifier/deepseek-2/output/hypervisor/1880763 new file mode 100644 index 000000000..396941dae --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1880763 @@ -0,0 +1,7 @@ + +Missing page crossing check in use_goto_tb() for rx target + +Currently the rx target doesn't have the page crossing check in its +use_goto_tb() function. +This is a required feature for stable system mode emulations that all +other targets implement. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1883728 b/results/classifier/deepseek-2/output/hypervisor/1883728 new file mode 100644 index 000000000..f15ec548e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1883728 @@ -0,0 +1,16 @@ + +address_space_unmap: Assertion `mr != NULL' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1884095 b/results/classifier/deepseek-2/output/hypervisor/1884095 new file mode 100644 index 000000000..4e2030b8e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/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/deepseek-2/output/hypervisor/1885247 b/results/classifier/deepseek-2/output/hypervisor/1885247 new file mode 100644 index 000000000..4565d6dc0 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1886076 b/results/classifier/deepseek-2/output/hypervisor/1886076 new file mode 100644 index 000000000..86f016b0f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1886076 @@ -0,0 +1,37 @@ + +risc-v pmp implementation error + +QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab + + +RISC-V PMP implementation is not correct on QEMU. + +When an access is granted there is no more PMP check on the 4KB memory range of the accessed location. +A cache flush is needed in order to force a PMP check on next access to this 4KB memory range. +A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range. + +For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF: +1st case: + 1) A read access is done @0x80003900 --> access OK as expected + 2) Then a read access is done @0x80003400 --> access OK while it must be blocked! +2nd case: + 1) A read access is done @0x80003900 --> access OK as expected + 2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");) + 3) A read access is done @0x80003400 --> access blocked as expected + +Analysis: + After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry. + Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed. +What should be done: + Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry. + +The 4KB range is the default size of a TLB page on QEMU for RISCV. +The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes. + +I tested a quick fix and PMP is working as expected. +The quick fix consist in replacing this line: +tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE); +By this one in target/riscv/cpu_helper.c: +tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size); + +This quick fix has to be optimized in order to consume less HW resources, as explained at the beginning. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1886318 b/results/classifier/deepseek-2/output/hypervisor/1886318 new file mode 100644 index 000000000..e3226ddbd --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/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/deepseek-2/output/hypervisor/1887 b/results/classifier/deepseek-2/output/hypervisor/1887 new file mode 100644 index 000000000..01dfec3df --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1887854 b/results/classifier/deepseek-2/output/hypervisor/1887854 new file mode 100644 index 000000000..dbe0da7a7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1887854 @@ -0,0 +1,24 @@ + +Spurious Data Abort on qemu-system-aarch64 + +When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is not yet publically available), the test generates a spurious data abort (the MMU and alignment checks should be disabled according to bits 1, 0 of SCTLR_EL1). The abort information is as follows: +Taking exception 4 [Data Abort] +...from EL1 to EL1 +...with ESR 0x25/0x96000010 +...with FAR 0x104010ca28 +...with ELR 0x400195d8 +...to EL1 PC 0x40018200 PSTATE 0x3c5 + +The ESR indicates that a synchronous external abort has occurred. +ESR EC field: 0b100101 + +From the ARMv8 technical manual: Data Abort taken without a change in Exception level. Used for MMU faults generated by data accesses, alignment faults other than those caused by Stack Pointer misalignment, and synchronous External aborts, including synchronous parity or ECC errors. Not used for debug related exceptions. + +ESR ISS field: 0b10000 + +From the ARMv8 technical manual: Synchronous External abort, not on translation table walk or hardware update of translation table. + +The following command line is used to invoke qemu: +qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot -nographic -serial mon:stdio -kernel build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d in_asm,int,cpu_reset,unimp,guest_errors + +This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as built by the RTEMS source builder (4.1+minor patches). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1888601 b/results/classifier/deepseek-2/output/hypervisor/1888601 new file mode 100644 index 000000000..9ee8b4911 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1888818 b/results/classifier/deepseek-2/output/hypervisor/1888818 new file mode 100644 index 000000000..c79c7245c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1888818 @@ -0,0 +1,50 @@ + +Multi-queue vhost-user fails to reconnect with qemu version >=4.2 + +Test Environment: +DPDK version: DPDK v20.08 +Other software versions: qemu4.2, qemu5.0. +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 8.4.0 +Hardware platform: Purley. +Test Setup +Steps to reproduce +List the steps to reproduce the issue. + +Test flow +========= +1. Launch vhost-user testpmd as port0 with 2 queues: + +./x86_64-native-linuxapp-gcc/app/testpmd -l 2-4 -n 4 \ + --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=2,client=1' -- -i --txd=1024 --rxd=1024 --txq=2 --rxq=2 +testpmd>start + +3. Launch qemu with virtio-net: + + taskset -c 13 \ + qemu-system-x86_64 -name us-vhost-vm1 \ + -cpu host -enable-kvm -m 2048 -object memory-backend-file,id=mem,size=2048M,mem-path=/mnt/huge,share=on \ + -numa node,memdev=mem \ + -mem-prealloc -monitor unix:/tmp/vm2_monitor.sock,server,nowait -netdev user,id=yinan,hostfwd=tcp:127.0.0.1:6005-:22 -device e1000,netdev=yinan \ + -smp cores=1,sockets=1 -drive file=/home/osimg/ubuntu16.img \ + -chardev socket,id=char0,path=./vhost-net,server \ + -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce,queues=2 \ + -device virtio-net-pci,mac=52:54:00:00:00:01,netdev=mynet1,mrg_rxbuf=on,csum=on,gso=on,host_tso4=on,guest_tso4=on,mq=on,vectors=15 \ + -vnc :10 -daemonize + +6. Quit testpmd and restart vhost-user : + +testpmd>quit +./x86_64-native-linuxapp-gcc/app/testpmd -l 2-4 -n 4 \ + --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=2,client=1' -- -i --txd=1024 --rxd=1024 --txq=2 --rxq=2 + + +Expected Result: +After the vhost-user is killed then re-launched, the virtio-net can connect back to vhost-user again. + +Actual Result: +Vhost-user relaunch failed with continous log printed"VHOST_CONFIG: Processing VHOST_USER_SET_FEATURES failed. + +Analysis: +This is a regression bug, bad commit: c6beefd674f +When vhost-user quits, QEMU doesnot save acked features for each virtio-net after vhost-user quits. When vhost-user reconnects to QEMU, QEMU sends two different features(one is the true acked feature while the another is 0x40000000) to vhost-user successively which causing vhost-user exits abnormally. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1888923 b/results/classifier/deepseek-2/output/hypervisor/1888923 new file mode 100644 index 000000000..dbaaee4ed --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1888923 @@ -0,0 +1,58 @@ + +Configured Memory access latency and bandwidth not taking effect + +I was trying to configure latencies and bandwidths between nodes in a NUMA emulation using QEMU 5.0.0. + +Host : Ubuntu 20.04 64 bit +Guest : Ubuntu 18.04 64 bit + +The machine configured has 2 nodes. Each node has 2 CPUs and has been allocated 3GB of memory. The memory access latencies and bandwidths for a local access (i.e from initiator 0 to target 0, and from initiator 1 to target 1) are set as 40ns and 10GB/s respectively. The memory access latencies and bandwidths for a remote access (i.e from initiator 1 to target 0, and from initiator 0 to target 1) are set as 80ns and 5GB/s respectively. + +The command line launch is as follows. + +sudo x86_64-softmmu/qemu-system-x86_64 \ +-machine hmat=on \ +-boot c \ +-enable-kvm \ +-m 6G,slots=2,maxmem=7G \ +-object memory-backend-ram,size=3G,id=m0 \ +-object memory-backend-ram,size=3G,id=m1 \ +-numa node,nodeid=0,memdev=m0 \ +-numa node,nodeid=1,memdev=m1 \ +-smp 4,sockets=4,maxcpus=4 \ +-numa cpu,node-id=0,socket-id=0 \ +-numa cpu,node-id=0,socket-id=1 \ +-numa cpu,node-id=1,socket-id=2 \ +-numa cpu,node-id=1,socket-id=3 \ +-numa dist,src=0,dst=1,val=20 \ +-net nic \ +-net user \ +-hda testing.img \ +-numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=40 \ +-numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +-numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=80 \ +-numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +-numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=80 \ +-numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +-numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,latency=40 \ +-numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ + +Then the latencies and bandwidths between the nodes were tested using the Intel Memory Latency Checker v3.9 (https://software.intel.com/content/www/us/en/develop/articles/intelr-memory-latency-checker.html). But the obtained results did not match the configuration. The following are the results obtained. + +Latency_matrix with idle latencies (in ns) + +Numa +Node 0 1 +0 36.2 36.4 +1 34.9 35.4 + +Bandwidth_matrix with memory bandwidths (in MB/s) + +Numa +Node 0 1 +0 15167.1 15308.9 +1 15226.0 15234.0 + +A test was also conducted with the tool “lat_mem_rd” from lmbench to measure the memory read latencies. This also gave results which did not match the config. + +Any information on why the config latency and bandwidth values are not applied, would be appreciated. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1888971 b/results/classifier/deepseek-2/output/hypervisor/1888971 new file mode 100644 index 000000000..7cc90f00e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/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 diff --git a/results/classifier/deepseek-2/output/hypervisor/1892441 b/results/classifier/deepseek-2/output/hypervisor/1892441 new file mode 100644 index 000000000..7fd643523 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1892441 @@ -0,0 +1,20 @@ + +"No zIPL section in IPL2 record" error when emulating Debian 10.5.0 on s390x + +Hi, + +I want to emulate Debian 10.5.0 for the s390x architecture. +The Debian image is downloaded from the following link: +https://cdimage.debian.org/debian-cd/current/s390x/iso-cd/debian-10.5.0-s390x-netinst.iso + +Using the latest QEMU version 5.1.0, running the debian image using the given command: +qemu-system-s390x -boot d -m 4096 -hda debian.qcow -cdrom debian-10.5.0-s390x-netinst.iso -nographic + +causes the error output below: + +LOADPARM=[ ] +Using virtio-blk. +Using guessed DASD geometry. +Using ECKD scheme (block size 4096), CDL + +! No zIPL section in IPL2 record. ! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1892541 b/results/classifier/deepseek-2/output/hypervisor/1892541 new file mode 100644 index 000000000..f04a588e5 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1893040 b/results/classifier/deepseek-2/output/hypervisor/1893040 new file mode 100644 index 000000000..516fc768f --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1894836 b/results/classifier/deepseek-2/output/hypervisor/1894836 new file mode 100644 index 000000000..c253ae401 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1894836 @@ -0,0 +1,47 @@ + +kernel panic using hvf with CPU passthrough + +Host Details +QEMU 5.1 (Homebrew) +macOS 10.15.6 Catalina +Late 2014 model +i5-4690 @ 3.5 GHz +8 GB RAM + +Guest Details +Ubuntu Desktop 20.04.1 Installer ISO + +Problem +Whenever I boot with "-accel hvf -cpu host", the Ubuntu desktop installer will immediately crash with a kernel panic after the initial splash screen. +See the attached picture of the kernel panic for more details. + +Steps to recreate +From https://www.jwillikers.com/posts/virtualize_ubuntu_desktop_on_macos_with_qemu/ + +1. Install QEMU with Homebrew. +$ brew install qemu + +2. Create a qcow2 disk image to which to install. +$ qemu-img create -f qcow2 ubuntu2004.qcow2 60G + +3. Download the ISO. +$ curl -L -o ubuntu-20.04.1-desktop-amd64.iso https://releases.ubuntu.com/20.04/ubuntu-20.04.1-desktop-amd64.iso + +4. Run the installer in QEMU. +$ qemu-system-x86_64 \ + -accel hvf \ + -cpu host \ + -smp 2 \ + -m 4G \ + -usb \ + -device usb-tablet \ + -vga virtio \ + -display default,show-cursor=on \ + -device virtio-net,netdev=vmnic -netdev user,id=vmnic \ + -audiodev coreaudio,id=snd0 \ + -device ich9-intel-hda -device hda-output,audiodev=snd0 \ + -cdrom ubuntu-20.04.1-desktop-amd64.iso \ + -drive file=ubuntu2004.qcow2,if=virtio + +Workaround +Emulating the CPU with "-cpu qemu64" does not result in a kernel panic. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1895053 b/results/classifier/deepseek-2/output/hypervisor/1895053 new file mode 100644 index 000000000..0243f9170 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1895053 @@ -0,0 +1,35 @@ + +Cannot nspawn raspbian 10 [FAILED] Failed to start Journal Service. + +Hi, I'm using nspawn and asked the question @systemd-devel. They redirected me to you, guessing that nspawn calls a syscall or ioctl qemu isnt aware of and can't implement properly? +They were like: "Sorry, that's not my department." ^^ + +Maybe you can reproduce the issue or help me investigating whats wrong or put the ball right back into their court? :D + +From: "chiasa.men" <email address hidden> +To: <email address hidden> +Date: 09.09.20 14:20 +(cf. https://github.com/systemd/systemd/issues/16975) + +Testscript: +wget https://downloads.raspberrypi.org/raspios_lite_armhf_latest -o r.zip +unzip r.zip +LOOP=$(losetup --show -Pf *raspios-buster-armhf-lite.img) +mount ${LOOP}p2 /mnt +mount ${LOOP}p1 /mnt/boot +systemd-nspawn --bind /usr/bin/qemu-arm-static --boot --directory=/mnt -- systemd.log_level=debug + + +Output: +see attachment + +System: +uname -a +Linux MArch 5.8.7-arch1-1 #1 SMP PREEMPT Sat, 05 Sep 2020 12:31:32 +0000 +x86_64 GNU/Linux + +systemd-nspawn --version +systemd 246 (246.4-1-arch) ++PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP ++GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN ++PCRE2 default-hierarchy=hybrid \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1898954 b/results/classifier/deepseek-2/output/hypervisor/1898954 new file mode 100644 index 000000000..b95dfb215 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1898954 @@ -0,0 +1,28 @@ + +x86 f1 opcode hangs qemu + +I have qemu installed and running in linux and windows +in linux i execute the following simple code in real mode of cpu in my vm +90 nop +90 nop +90 nop +f1 ;this should conjure up my interrupt handler from ivt int 1 +--------- end of code ---- +it works properly in vbox,qemu linux,and even in my boot loder +on a real platform + it doeas not work fine in windows 10 (32 bit efi) based qemu +--- +all of the below was retyped there may be typo +so onwards to the flawed software +********** for qemu-system-x86_64.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +********** for qemu-system-i386.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +*********************************************** +my startup code is +"d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" -cpu Nehalem -machine pc +--- +also same flaw if i change above section to +"d:\programs\qemu\qemu-system-i386.exe" \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1900241 b/results/classifier/deepseek-2/output/hypervisor/1900241 new file mode 100644 index 000000000..c768d6923 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1900241 @@ -0,0 +1,116 @@ + +[regression][powerpc] some vcpus are found offline inside guest with different vsmt setting from qemu-cmdline and breaks subsequent vcpu hotplug operation (xive) + +Env: +Host: Power9 HW ppc64le + +# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 128 +On-line CPU(s) list: 24-31,40-159 +Thread(s) per core: 4 +Core(s) per socket: 16 +Socket(s): 2 +NUMA node(s): 2 +Model: 2.3 (pvr 004e 1203) +Model name: POWER9, altivec supported +Frequency boost: enabled +CPU max MHz: 3800.0000 +CPU min MHz: 2300.0000 +L1d cache: 1 MiB +L1i cache: 1 MiB +L2 cache: 8 MiB +L3 cache: 160 MiB +NUMA node0 CPU(s): 24-31,40-79 +NUMA node8 CPU(s): 80-159 +Vulnerability Itlb multihit: Not affected +Vulnerability L1tf: Mitigation; RFI Flush, L1D private per thread +Vulnerability Mds: Not affected +Vulnerability Meltdown: Mitigation; RFI Flush, L1D private per thread +Vulnerability Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) +Vulnerability Spectre v1: Mitigation; __user pointer sanitization, ori31 speculation barrier enabled +Vulnerability Spectre v2: Mitigation; Software count cache flush (hardware accelerated), Software link stack flush +Vulnerability Srbds: Not affected +Vulnerability Tsx async abort: Not affected + + + +Host Kernel: 5.9.0-0.rc8.28.fc34.ppc64le (Fedora rawhide) +Guest Kernel: Fedora33(5.8.6-301.fc33.ppc64le) + +Qemu: e12ce85b2c79d83a340953291912875c30b3af06 (qemu/master) + + +Steps to reproduce: + +Boot below kvm guest: (-M pseries,vsmt=2 -smp 8,cores=8,threads=1) + + /home/sath/qemu/build/qemu-system-ppc64 -name vm1 -M pseries,vsmt=2 -accel kvm -m 4096 -smp 8,cores=8,threads=1 -nographic -nodefaults -serial mon:stdio -vga none -nographic -device virtio-scsi-pci -drive file=/home/sath/tests/data/avocado-vt/images/fdevel-ppc64le.qcow2,if=none,id=hd0,format=qcow2,cache=none -device scsi-hd,drive=hd0 + + +lscpu inside guest: +Actual: +[root@atest-guest ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 8 +On-line CPU(s) list: 0,2,4,6 +Off-line CPU(s) list: 1,3,5,7 --------------------------NOK +Thread(s) per core: 1 +Core(s) per socket: 4 +Socket(s): 1 +NUMA node(s): 1 +Model: 2.3 (pvr 004e 1203) +Model name: POWER9 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 128 KiB +L1i cache: 128 KiB +NUMA node0 CPU(s): 0,2,4,6 +Vulnerability Itlb multihit: Not affected +Vulnerability L1tf: Mitigation; RFI Flush, L1D private per thread +Vulnerability Mds: Not affected +Vulnerability Meltdown: Mitigation; RFI Flush, L1D private per thread +Vulnerability Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) +Vulnerability Spectre v1: Mitigation; __user pointer sanitization, ori31 + speculation barrier enabled +Vulnerability Spectre v2: Mitigation; Software count cache flush (hardwar + e accelerated), Software link stack flush +Vulnerability Srbds: Not affected +Vulnerability Tsx async abort: Not affected + + +Expected: + +[root@atest-guest ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 8 +On-line CPU(s) list: 0-7 +Thread(s) per core: 1 +Core(s) per socket: 8 +Socket(s): 1 +NUMA node(s): 1 +Model: 2.3 (pvr 004e 1203) +Model name: POWER9 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 256 KiB +L1i cache: 256 KiB +NUMA node0 CPU(s): 0-7 +Vulnerability Itlb multihit: Not affected +Vulnerability L1tf: Mitigation; RFI Flush, L1D private per thread +Vulnerability Mds: Not affected +Vulnerability Meltdown: Mitigation; RFI Flush, L1D private per thread +Vulnerability Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) +Vulnerability Spectre v1: Mitigation; __user pointer sanitization, ori31 + speculation barrier enabled +Vulnerability Spectre v2: Mitigation; Software count cache flush (hardwar + e accelerated), Software link stack flush +Vulnerability Srbds: Not affected +Vulnerability Tsx async abort: Not affected + + + +There by further vcpuhotplug operation fails... \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1902267 b/results/classifier/deepseek-2/output/hypervisor/1902267 new file mode 100644 index 000000000..adc58e9a8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1902267 @@ -0,0 +1,32 @@ + +CPU not support 32-bit stack in 32-bit unreal mode + +QEMU version 5.0.0 supports 32-bit and 16-bit unreal mode. Great! +Unfortunately, QEMU does not support 32-bit stack in unreal 32-bit mode. +After the INT instruction, the stack is switched to 16-bit, which should not be the case. +At BOCHS, my code works 100%. At QEMU not works. + +Sample code to find out: + +use32 +cli +mov ax,cs +shl eax,16 +mov ax,NewInt80h +mov [IDT32+4*80h],eax +mov edx,esp +mov esp,0x10000 +int 80h +NewInt80h: +xchg esp,edx +cmp edx,0x10000-6 +jnz IsStack16Bit + +Stack selector loaded from GDT: +GDT: +real32_GDT +dq 0 +dw 0xFFFF,0x0000,9A00h,0xCF ; 32-bit code descriptor +dw 0xFFFF,0x0000,9200h,0x8F ; 4 GB data descriptor +dw 0xFFFF,0x0000,9A00h,0x00 ; 16-bit code descriptor +dw 0xFFFF,0x0000,9200h,0xCF ; 32-bit data descriptor stack \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1902777 b/results/classifier/deepseek-2/output/hypervisor/1902777 new file mode 100644 index 000000000..e23cb0435 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1904317 b/results/classifier/deepseek-2/output/hypervisor/1904317 new file mode 100644 index 000000000..fc7ae78b6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1905562 b/results/classifier/deepseek-2/output/hypervisor/1905562 new file mode 100644 index 000000000..9286be8cc --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1905562 @@ -0,0 +1,31 @@ + +Guest seems suspended after host freed memory for it using oom-killer + +Host: qemu 5.1.0, linux 5.5.13 +Guest: Windows 7 64-bit + +This guest ran a memory intensive process, and triggered oom-killer on host. Luckily, it killed chromium. My understanding is this should mean qemu should have continued running unharmed. But, the spice connection shows the host system clock is stuck at the exact time oom-killer was triggered. The host is completely unresponsive. + +I can telnet to the qemu monitor. "info status" shows "running". But, multiple times running "info registers -a" and saving the output to text files shows the registers are 100% unchanged, so it's not really running. + +On the host, top shows around 4% CPU usage by qemu. strace shows about 1,000 times a second, these 6 lines repeat: + +0.000698 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c10) = 0 <0.000010> +0.000034 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c60) = 0 <0.000009> +0.000031 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c20) = 0 <0.000007> +0.000028 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c70) = 0 <0.000007> +0.000030 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events =POLLIN}, {fd=16, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLI N}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}], 16, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) <0.000009> +0.000043 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events =POLLIN}, {fd=16, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLI N}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}], 16, {tv_sec=0, tv_nsec=769662}, NULL, 8) = 0 (Tim eout) <0.000788> + +In the monitor, "info irq" shows IRQ 0 is increasing about 1,000 times a second. IRQ 0 seems to be for the system clock, and 1,000 times a second seems to be the frequency a windows 7 guest might have the clock at. + +Those fd's are for: (9) [eventfd]; [signalfd], type=STREAM, 4 x the spice socket file, and "TCP localhost:ftnmtp->localhost:36566 (ESTABLISHED)". + +Because the guest's registers aren't changing, it seems to me like monitor thinks the VM is running, but it's actually effectively in a paused state. I think all the strace activity shown above must be generated by the host. Perhaps it's repeatedly trying to contact the guest to inject a new clock, and communicate with it on the various eventfd's, spice socket, etc. So, I'm thinking the strace doesn't give any information about the real reason why the VM is acting as if it's paused. + +I've checked "info block", and there's nothing showing that a device is paused, or that there's any issues with them. (Can't remember what term can be there, but a paused/blocked/etc block device I think caused a VM to act like this for me in the past.) + + +Is there something I can provide to help fix the bug here? + +Is there something I can do, to try to get the VM running again? (I sadly have unsaved work in it.) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1908489 b/results/classifier/deepseek-2/output/hypervisor/1908489 new file mode 100644 index 000000000..71da3147e --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1908781 b/results/classifier/deepseek-2/output/hypervisor/1908781 new file mode 100644 index 000000000..bb5d71ced --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1908781 @@ -0,0 +1,10 @@ + +x86-64 not faulting when CS.L = 1 and CS.D = 1 + +In a UEFI application I accidentally created a code segment descriptor where both the L and D bits were 1. This is supposed to generate a GP fault (e.g. see page 2942 of https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf). When running with KVM a fault did indeed occur, but when not specifying any acceleration, no fault occurred. + +Let me know if you need me to develop a minimum example to debug from. At the moment it's all part of a slightly more complicated bit of code. + +Version: 5.2.0 (compiled from source) +Command line options: -smp cores=4 -m 8192 (plus whatever uefi-run adds to plug in OVMF and my UEFI application). +Environment: Ubuntu 20.04 on Ryzen 3700X \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1909921 b/results/classifier/deepseek-2/output/hypervisor/1909921 new file mode 100644 index 000000000..fb0a10974 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1910 b/results/classifier/deepseek-2/output/hypervisor/1910 new file mode 100644 index 000000000..de8546694 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1910 @@ -0,0 +1,63 @@ + +Signal handlers in x86_64 userspace have wrongly aligned stack +Description of problem: +Various applications crash in signal handlers due to `movaps` getting a misaligned stack address. For some reason this is reported as a NULL deref, but `gdb` clearly shows the true cause. + +```plaintext +> qemu-x86_64 /usr/bin/ruby -e '`true`' +-e:1: [BUG] Segmentation fault at 0x0000000000000000 +ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-gnu] + +-- Control frame information ----------------------------------------------- +c:0003 p:---- s:0011 e:000010 CFUNC :` +c:0002 p:0005 s:0006 e:000005 EVAL -e:1 [FINISH] +c:0001 p:0000 s:0003 E:0015b0 DUMMY [FINISH] + +-- Ruby level backtrace information ---------------------------------------- +-e:1:in `<main>' +-e:1:in ``' + +-- Machine register context ------------------------------------------------ + RIP: 0x00002aaaab50f98a RBP: 0x00002aaaabb136b8 RSP: 0x00002aaaab2a9c98 + RAX: 0x0000000000000000 RBX: 0x0000000000004946 RCX: 0x0000000000000000 + RDX: 0x00002aaaab2a9c98 RDI: 0x000000000caf0000 RSI: 0x0000000000000000 + R8: 0x00002aaaab2aaa50 R9: 0x0000000000000050 R10: 0x0000000000000008 + R11: 0x0000000000000000 R12: 0x0000000000000002 R13: 0x0000000000007310 + R14: 0x0000000000005e10 R15: 0x00002aaab0537f20 EFL: 0x0000000000000246 + +-- C level backtrace information ------------------------------------------- +``` + +```plaintext +(gdb) x/i $pc +=> 0x2aaaab50f98a: movaps %xmm0,(%rsp) +(gdb) p/x $rsp +$3 = 0x2aaaab2a9998 +``` +Steps to reproduce: +1. ```qemu-x86_64 /usr/bin/ruby -e '`true`'``` +Additional information: +The x86_64 psABI says: + +> the value (%rsp − 8) is always a multiple of 16 when control is transferred to the function entry point. + +However, when QEMU jumps to the signal handler, $rsp is aligned to 16B, i.e. ends in `0x..0`. + +The relevant kernel code: + +https://elixir.bootlin.com/linux/v6.5.5/source/arch/x86/kernel/signal.c#L123 + +```plaintext + sp -= frame_size; + + if (ia32_frame) + /* + * Align the stack pointer according to the i386 ABI, + * i.e. so that on function entry ((sp + 4) & 15) == 0. + */ + sp = ((sp + 4) & -FRAME_ALIGNMENT) - 4; + else + sp = round_down(sp, FRAME_ALIGNMENT) - 8; +``` + +CC @lvivier @bonzini @rth7680 diff --git a/results/classifier/deepseek-2/output/hypervisor/1911351 b/results/classifier/deepseek-2/output/hypervisor/1911351 new file mode 100644 index 000000000..18953dda2 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1912224 b/results/classifier/deepseek-2/output/hypervisor/1912224 new file mode 100644 index 000000000..ee7d6e0e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1912224 @@ -0,0 +1,128 @@ + +qemu may freeze during drive-mirroring on fragmented FS + + +We have odd behavior in operation where qemu freeze during long +seconds, We started an thread about that issue here: +https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05623.html + +It happens at least during openstack nova snapshot (qemu blockdev-mirror) +or live block migration(which include network copy of disk). + +After further troubleshoots, it seems related to FS fragmentation on host. + +reproducible at least on: +Ubuntu 18.04.3/4.18.0-25-generic/qemu-4.0 +Ubuntu 16.04.6/5.10.6/qemu-5.2.0-rc2 + +# Lets create a dedicated file system on a SSD/Nvme 60GB disk in my case: +$sudo mkfs.ext4 /dev/sda3 +$sudo mount /dev/sda3 /mnt +$df -h /mnt +Filesystem Size Used Avail Use% Mounted on +/dev/sda3 59G 53M 56G 1% /mnt + +#Create a fragmented disk on it using 2MB Chunks (about 30min): +$sudo python3 create_fragged_disk.py /mnt 2 +Filling up FS by Creating chunks files in: /mnt/chunks +We are probably full as expected!!: [Errno 28] No space left on device +Creating fragged disk file: /mnt/disk + +$ls -lhs +59G -rw-r--r-- 1 root root 59G Jan 15 14:08 /mnt/disk + +$ sudo e4defrag -c /mnt/disk + Total/best extents 41971/30 + Average size per extent 1466 KB + Fragmentation score 2 + [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag] + This file (/mnt/disk) does not need defragmentation. + Done. + +# the tool^^^ says it is not enough fragmented to be able to defrag. + +#Inject an image on fragmented disk +sudo chown ubuntu /mnt/disk +wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img +qemu-img convert -O raw bionic-server-cloudimg-amd64.img \ + bionic-server-cloudimg-amd64.img.raw +dd conv=notrunc iflag=fullblock if=bionic-server-cloudimg-amd64.img.raw \ + of=/mnt/disk bs=1M +virt-customize -a /mnt/disk --root-password password:xxxx + +# logon run console activity ex: ping -i 0.3 127.0.0.1 +$qemu-system-x86_64 -m 2G -enable-kvm -nographic \ + -chardev socket,id=test,path=/tmp/qmp-monitor,server,nowait \ + -mon chardev=test,mode=control \ + -drive file=/mnt/disk,format=raw,if=none,id=drive-virtio-disk0,cache=none,discard\ + -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on + +$sync +$echo 3 | sudo tee -a /proc/sys/vm/drop_caches + +#start drive-mirror via qmp on another SSD/nvme partition +nc -U /tmp/qmp-monitor +{"execute":"qmp_capabilities"} +{"execute":"drive-mirror","arguments":{"device":"drive-virtio-disk0","target":"/home/ubuntu/mirror","sync":"full","format":"qcow2"}} +^^^ qemu console may start to freeze at this step. + +NOTE: + - smaller chunk sz and bigger disk size the worst it is. + In operation we also have issue on 400GB disk size with average 13MB/extent + - Reproducible also on xfs + + +Expected behavior: +------------------- +QEMU should remain steady, eventually only have decrease storage Performance +or mirroring, because of fragmented fs. + +Observed behavior: +------------------- +Perf of mirroring is still quite good even on fragmented FS, +but it breaks qemu. + + +###################### create_fragged_disk.py ############ +import sys +import os +import tempfile +import glob +import errno + +MNT_DIR = sys.argv[1] +CHUNK_SZ_MB = int(sys.argv[2]) +CHUNKS_DIR = MNT_DIR + '/chunks' +DISK_FILE = MNT_DIR + '/disk' + +if not os.path.exists(CHUNKS_DIR): + os.makedirs(CHUNKS_DIR) + +with open("/dev/urandom", "rb") as f_rand: + mb_rand=f_rand.read(1024 * 1024) + +print("Filling up FS by Creating chunks files in: ",CHUNKS_DIR) +try: + while True: + tp = tempfile.NamedTemporaryFile(dir=CHUNKS_DIR,delete=False) + for x in range(CHUNK_SZ_MB): + tp.write(mb_rand) + os.fsync(tp) + tp.close() +except Exception as ex: + print("We are probably full as expected!!: ",ex) + +chunks = glob.glob(CHUNKS_DIR + '/*') + +print("Creating fragged disk file: ",DISK_FILE) +with open(DISK_FILE, "w+b") as f_disk: + for chunk in chunks: + try: + os.unlink(chunk) + for x in range(CHUNK_SZ_MB): + f_disk.write(mb_rand) + os.fsync(f_disk) + except IOError as ex: + if ex.errno != errno.ENOSPC: + raise +###########################################################3 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1914294 b/results/classifier/deepseek-2/output/hypervisor/1914294 new file mode 100644 index 000000000..d3b47bd6e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1914294 @@ -0,0 +1,14 @@ + +Windows XP displays black screen when smp option is used + +When I use Windows XP with the -smp option, the screen goes black. The only thing I can see is a cursor. I have tried -smp 2, -smp cores=4, and -smp cores=2. + +My info: + +Host: +M1 Mac +Mac OS 11.1 +QEMU 5.2 at cf7ca7d5b9faca13f1f8e3ea92cfb2f741eb0c0e. + +Guest: +32-bit Windows XP SP3 build 2600. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1915027 b/results/classifier/deepseek-2/output/hypervisor/1915027 new file mode 100644 index 000000000..852fe347a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1915027 @@ -0,0 +1,10 @@ + +RISC-V 64, CPUs do ilegal 0x00 write with SMP + +When QEMU is runt like this: + +qemu-system-riscv64 -d unimp,guest_errors -smp 8 + +Other harts will do a illegal write on address 0x00. + +This could be mostly (i think) because the initial assembly code is only loaded on the first hart and the others do a mess because there is no code to execute. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1915063 b/results/classifier/deepseek-2/output/hypervisor/1915063 new file mode 100644 index 000000000..fddaecb75 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1915063 @@ -0,0 +1,15 @@ + +Windows 10 wil not install using qemu-system-x86_64 + +Steps to reproduce +install virt-manager and ovmf if nopt already there +copy windows and virtio iso files to /var/lib/libvirt/images + +Use virt-manager from local machine to create your VMs with the disk, CPUs and memory required + Select customize configuration then select OVMF(UEFI) instead of seabios + set first CDROM to the windows installation iso (enable in boot options) + add a second CDROM and load with the virtio iso + change spice display to VNC + + Always get a security error from windows and it fails to launch the installer (works on RHEL and Fedora) +I tried updating the qemu version from Focals 4.2 to Groovy 5.0 which was of no help \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1916112 b/results/classifier/deepseek-2/output/hypervisor/1916112 new file mode 100644 index 000000000..1c7d16368 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1916112 @@ -0,0 +1,60 @@ + +Illegal instruction crash of QEMU on Jetson Nano + +I have a jetson nano (arm64 SBC) and I want to check the native emulation performance of Raspbian Buster. I used the info available here: + +https://github.com/dhruvvyas90/qemu-rpi-kernel/tree/master/native-emuation + +I have Xubuntut 20.04 with KVM enabled kernel running on the Jetson Nano + +However QEMU crashes with "Illegal Instruction" during kernel boot. I have a built latest QEMU from sources with following configuration + +./configure --prefix=/usr/local --target-list=aarch64-softmmu,arm-softmmu --enable-guest-agent --enable-vnc --enable-vnc-jpeg --enable-vnc-png --enable-kvm --enable-spice --enable-sdl --enable-gtk --enable-virglrenderer --enable-opengl + +qemu-system-aarch64 --version +QEMU emulator version 5.2.50 (v5.2.0-1731-g5b19cb63d9) + +When I run as follows: + +../build/qemu-system-aarch64 -M raspi3 +-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1" +-dtb ./bcm2710-rpi-3-b-plus.dtb +-sd /media/96747D21747D0571/JetsonNano/2020-08-20-raspios-buster-armhf-full.qcow2 +-kernel ./kernel8.img +-m 1G -smp 4 -serial stdio -usb -device usb-mouse -device usb-kbd + +I get : +[ 74.994834] systemd[1]: Condition check resulted in FUSE Control File System being skipped. +[ 76.281274] systemd[1]: Starting Apply Kernel Variables... +Starting Apply Kernel Variables... +Illegal instruction (core dumped) + +When I use GDB I see this: + +Thread 8 "qemu-system-aar" received signal SIGILL, Illegal instruction. +[Switching to Thread 0x7fad7f9ba0 (LWP 28037)] +0x0000007f888ac690 in code_gen_buffer () +(gdb) bt +#0 0x0000007f888ac690 in code_gen_buffer () +#1 0x0000005555d7c038 in cpu_tb_exec (tb_exit=, itb=, cpu=0x7fb4502c40) +at ../accel/tcg/cpu-exec.c:191 +#2 cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, cpu=0x7fb4502c40) +at ../accel/tcg/cpu-exec.c:708 +#3 cpu_exec (cpu=cpu@entry=0x7fb4502c40) at ../accel/tcg/cpu-exec.c:819 +.. + +I have just two questions: + +Is this a problem with QEMU or is there anything specific build or options I need to use. Any specific version of QEMU should be used ? + +Why is TCG used as the accelerator when KVM is present. Is it possible and how to use KVM ? + +If I enabled the KVM then I get this error: + +../build/qemu-system-aarch64 -M raspi3 -enable-kvm -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1" -dtb ./bcm2710-rpi-3-b-plus.dtb -sd /media/96747D21747D0571/JetsonNano/2020-08-20-raspios-buster-armhf-full.qcow2 -kernel ./kernel8.img -m 1G -smp 4 -serial stdio -usb -device usb-mouse -device usb-kbd +WARNING: Image format was not specified for '/media/96747D21747D0571/JetsonNano/2020-08-20-raspios-buster-armhf-full.img' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. +qemu-system-aarch64: ../softmmu/physmem.c:750: cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()' failed. + +Thanks a lot. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1917 b/results/classifier/deepseek-2/output/hypervisor/1917 new file mode 100644 index 000000000..d2bd36631 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1917184 b/results/classifier/deepseek-2/output/hypervisor/1917184 new file mode 100644 index 000000000..375c971f6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1917184 @@ -0,0 +1,6 @@ + +qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip + +When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault. + +qemu version 5.2.0, x86-64 host. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1918302 b/results/classifier/deepseek-2/output/hypervisor/1918302 new file mode 100644 index 000000000..4b28bac2a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1918302 @@ -0,0 +1,13 @@ + +qemu-system-arm segfaults while servicing SYS_HEAPINFO + +I compiled QEMU version 5.2.0 from source on Ubuntu 18.04, and tried to use it to run the attached bare-metal Arm hello-world image, using the command line + +qemu-system-arm -M microbit -semihosting -nographic -device loader,file=hello.hex + +The result was that qemu-system-arm itself died of a segfault. Compiling it for debugging, the location of the segfault was in target/arm/arm-semi.c, in the case handler for the semihosting call TARGET_SYS_HEAPINFO, on line 1020 which assigns to 'rambase': + + const struct arm_boot_info *info = env->boot_info; + target_ulong rambase = info->loader_start; + +and the problem seems to be that 'info', aka env->boot_info, is NULL in this context. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1920784 b/results/classifier/deepseek-2/output/hypervisor/1920784 new file mode 100644 index 000000000..772f2ab53 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1920784 @@ -0,0 +1,69 @@ + +qemu-system-ppc64le fails with kvm acceleration + +(Suspected glibc issue!) + +qemu-system-ppc64(le) fails when invoked with kvm acceleration with error "illegal instruction" + +> qemu-system-ppc64(le) -M pseries,accel=kvm + +Illegal instruction (core dumped) + +In dmesg: + +Facility 'SCV' unavailable (12), exception at 0x7624f8134c0c, MSR=900000000280f033 + + +Version-Release number of selected component (if applicable): +qemu 5.2.0 +Linux kernel 5.11 +glibc 2.33 +all latest updates as of submitting the bug report + +How reproducible: +Always + +Steps to Reproduce: +1. Run qemu with kvm acceleration + +Actual results: +Illegal instruction + +Expected results: +Normal VM execution + +Additional info: +The machine is a Raptor Talos II Lite with a Sforza V1 8-core, but was also observed on a Raptor Blackbird with the same processor. + +This was also observed on Fedora 34 beta, which uses glibc 2.33 +Also tested on ArchPOWER (unofficial port of Arch Linux for ppc64le) with glibc 2.33 +Fedora 33 and Ubuntu 20.10, both using glibc 2.32 do not have this issue, and downgrading the Linux kernel from 5.11 to 5.4 LTS on ArchPOWER solved the problem. Kernel 5.9 and 5.10 have the same issue when combined with glibc2.33 + +ProblemType: Bug +DistroRelease: Ubuntu 21.04 +Package: qemu-system 1:5.2+dfsg-6ubuntu2 +ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0 +Uname: Linux 5.11.0-11-generic ppc64le +.sys.firmware.opal.msglog: Error: [Errno 13] Permission denied: '/sys/firmware/opal/msglog' +ApportVersion: 2.20.11-0ubuntu60 +Architecture: ppc64el +CasperMD5CheckResult: pass +CurrentDesktop: Unity:Unity7:ubuntu +Date: Mon Mar 22 14:48:39 2021 +InstallationDate: Installed on 2021-03-22 (0 days ago) +InstallationMedia: Ubuntu-Server 21.04 "Hirsute Hippo" - Alpha ppc64el (20210321) +KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND +ProcKernelCmdLine: root=UUID=f3d03315-0944-4a02-9c87-09c00eba9fa1 ro +ProcLoadAvg: 1.20 0.73 0.46 1/1054 6071 +ProcSwaps: + Filename Type Size Used Priority + /swap.img file 8388544 0 -2 +ProcVersion: Linux version 5.11.0-11-generic (buildd@bos02-ppc64el-002) (gcc (Ubuntu 10.2.1-20ubuntu1) 10.2.1 20210220, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #12-Ubuntu SMP Mon Mar 1 19:26:20 UTC 2021 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +VarLogDump_list: total 0 +acpidump: + +cpu_cores: Number of cores present = 8 +cpu_coreson: Number of cores online = 8 +cpu_smt: SMT=4 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1921082 b/results/classifier/deepseek-2/output/hypervisor/1921082 new file mode 100644 index 000000000..dc135037e --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1921280 b/results/classifier/deepseek-2/output/hypervisor/1921280 new file mode 100644 index 000000000..7780f5b42 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1921280 @@ -0,0 +1,8 @@ + +OpenIndiana stuck in boot loop when using hvf + +I'm using QEMU version 5.2.0 on macOS, and running the "OpenIndiana Hipster 2020.10 Text Install DVD (64-bit x86)" ISO: + +qemu-system-x86_64 -cdrom ~/Downloads/OI-hipster-text-20201031.iso -m 2048 -accel hvf -cpu host + +It gets to "Booting...", stays there for a bit, and then restarts. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1921948 b/results/classifier/deepseek-2/output/hypervisor/1921948 new file mode 100644 index 000000000..2746deb9e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1921948 @@ -0,0 +1,39 @@ + +MTE tags not checked properly for unaligned accesses at EL1 + +For kernel memory accesses that span across two memory granules, QEMU's MTE implementation only checks the tag of the first granule but not of the second one. + +To reproduce this, build the Linux kernel with CONFIG_KASAN_HW_TAGS enabled, apply the patch below, and boot the kernel: + +diff --git a/sound/last.c b/sound/last.c +index f0bb98780e70..04745cb30b74 100644 +--- a/sound/last.c ++++ b/sound/last.c +@@ -5,12 +5,18 @@ + */ + + #include <linux/init.h> ++#include <linux/slab.h> + #include <sound/core.h> + + static int __init alsa_sound_last_init(void) + { + struct snd_card *card; + int idx, ok = 0; ++ ++ char *ptr = kmalloc(128, GFP_KERNEL); ++ pr_err("KASAN report should follow:\n"); ++ *(volatile unsigned long *)(ptr + 124); ++ kfree(ptr); + + printk(KERN_INFO "ALSA device list:\n"); + for (idx = 0; idx < SNDRV_CARDS; idx++) { + +KASAN tags the 128 allocated bytes with the same tag as the returned pointer. The memory granule that follows the 128 allocated bytes has a different tag (with 1/15 probability). + +Expected result: a tag fault is detected and a KASAN report is printed when accessing bytes [124, 130). +Observed result: no tag fault is detected and no KASAN report is printed. + +Here are the flags that I use to run QEMU if they matter: + +qemu-system-aarch64 -s -machine virt,mte=on -cpu max -m 2G -smp 2 -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 -net nic -nographic -kernel ./Image -append "console=ttyAMA0 root=/dev/vda earlyprintk=serial" -drive file=./fs.img,format=raw,if=virtio -no-shutdown -no-reboot \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1922 b/results/classifier/deepseek-2/output/hypervisor/1922 new file mode 100644 index 000000000..ca2aa9b3d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1922 @@ -0,0 +1,21 @@ + +loongson3-virt machine fails to bring up secondary CPUs +Description of problem: +When booting Debian netboot on `loongson3-virt` machine with SMP, cores other than number 0 fail to come up. Boot without SMP is successful. + +I provided the details of the first combination I tested, but I have also tested on an x86_64 host, as well as with Debian 11 (kernel `5.10.0-22-loongson-3`) on both hosts, with the same results. +Steps to reproduce: +1. `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/vmlinuz-6.1.0-10-loongson-3` +2. `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/initrd.gz` +3. `qemu-system-mips64el -M loongson3-virt -kernel vmlinuz-6.1.0-10-loongson-3 -initrd initrd.gz -append "console=ttyS0" -serial stdio -smp 2` +Additional information: +Boot is successful when removing `-smp 2` from command line. With it present, the following error is in `dmesg` (extends to all other CPUs when a larger SMP value is passed): +``` +[ 2.248229] rcu: Hierarchical SRCU implementation. +[ 2.248446] rcu: Max phase no-delay instances is 1000. +[ 2.647997] smp: Bringing up secondary CPUs ... +[ 2.749706] Booting CPU#1... +[ 7.093229] CPU1: failed to start +[ 7.096508] smp: Brought up 1 node, 1 CPU +``` +The boot eventually stalls after this. diff --git a/results/classifier/deepseek-2/output/hypervisor/1925094 b/results/classifier/deepseek-2/output/hypervisor/1925094 new file mode 100644 index 000000000..c389968a4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1925094 @@ -0,0 +1,6 @@ + +DISCARD support for Crypto Block Devices + +It appears that running `fstrim` or similar is useless when the VM is on a LUKS-encrypted device using QEMU's native LUKS support. + +Looking at the source, it seems that block/crypto.c lacks an implementation for bdrv_co_pdiscard, which probably needs to delegate to a per-crypto type discard helper. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1926249 b/results/classifier/deepseek-2/output/hypervisor/1926249 new file mode 100644 index 000000000..165076c50 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1926249 @@ -0,0 +1,20 @@ + +postcopy migration fails in hirsute (solved) + +FYI: this is an intended change, can be overwritten via config and this bug is mostly to have something puzzled users can find via search engines to explain and solve their issue. + +postcopy migration can in some cases be very useful +=> https://wiki.qemu.org/Features/PostCopyLiveMigration + +But with Hirsute kernel being 5.11 that now contains the following upstream change +=> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0d4730ac2 + +Due to that postcopy migration will fail like: + ++ lxc exec testkvm-focal-from -- virsh migrate --unsafe --live --postcopy --postcopy-after-precopy kvmguest-focal-postcopy qemu+ssh://10.85.93.248/system +error: internal error: unable to execute QEMU command 'migrate-set-capabilities': Postcopy is not supported + +This will also apply to e.g. a Focal-HWE kernel once on v5.11 or to Focal userspaces in a container under a Hirsute kernel (that is the example above). + +This was done for security reasons, if you want/need to re-enable un-limited userfault handling to be able to use postcopy again you'd want/need to set the control knob to one like: +$ sudo sysctl -w "vm.unprivileged_userfaultfd=1" \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1926596 b/results/classifier/deepseek-2/output/hypervisor/1926596 new file mode 100644 index 000000000..d3d14ce10 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1926596 @@ -0,0 +1,35 @@ + +qemu-monitor-event command gets stuck randomly + +We are using kvm virtualization on our servers, We use "qemu-monitor-command"(drive-backup) to take qcow2 backups and to monitor them we use "qemu-monitor-event" command +For eg:- +/usr/bin/virsh qemu-monitor-event VPSNAME --event "BLOCK_JOB_COMPLETED\|BLOCK_JOB_ERROR" --regex + +the above command stucks randomly (backup completes but still it is waiting) and because of which other vms backup are stucked until we kill that process. + +Can you suggest how can we debug this further to find the actual issue. + + +/usr/bin/virsh version + +Compiled against library: libvirt 4.5.0 +Using library: libvirt 4.5.0 +Using API: QEMU 4.5.0 +Running hypervisor: QEMU 2.0.0 + +cat /etc/os-release +NAME="CentOS Linux" +VERSION="7 (Core)" +ID="centos" +ID_LIKE="rhel fedora" +VERSION_ID="7" +PRETTY_NAME="CentOS Linux 7 (Core)" +ANSI_COLOR="0;31" +CPE_NAME="cpe:/o:centos:centos:7" +HOME_URL="https://www.centos.org/" +BUG_REPORT_URL="https://bugs.centos.org/" + +CENTOS_MANTISBT_PROJECT="CentOS-7" +CENTOS_MANTISBT_PROJECT_VERSION="7" +REDHAT_SUPPORT_PRODUCT="centos" +REDHAT_SUPPORT_PRODUCT_VERSION="7" \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1945 b/results/classifier/deepseek-2/output/hypervisor/1945 new file mode 100644 index 000000000..9c41fe0eb --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1945 @@ -0,0 +1,2 @@ + +More than 8 cores for RISC-V generic `virt` machine diff --git a/results/classifier/deepseek-2/output/hypervisor/1947933 b/results/classifier/deepseek-2/output/hypervisor/1947933 new file mode 100644 index 000000000..598a3ed22 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1947933 @@ -0,0 +1,15 @@ + +xHCI Port Status Change Event at port powered + +Per section 4.19.3 of the xHCI version 1.0 specification, when the Port Power bit transitions from 0 to 1, if there is a connection on that port, a Port Status Change Event should be issued. + +Currently, when the port is powered, this event is not being issued. + +I don't know the QEMU code base well enough to submit a patch, but I believe that when the port is powered, check to see if there is a connection (hence, setting the CCS and CSC bits), and then a call to: + +xhci_port_notify(port, PORTSC_PLC); + +will suffice. + +Thank you, +Ben \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1948 b/results/classifier/deepseek-2/output/hypervisor/1948 new file mode 100644 index 000000000..4f2698063 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1948 @@ -0,0 +1,4 @@ + +ARM GICv3 cannot support irq number > 992 +Description of problem: +If we want to create a gic with supported irq number 992, we need to set the `num-irq` property to 992 + 32 while 32 is the extra SGI number. But there is a problem, when QEMU initialize GICv3, it will check the variable `num_irq <= 1020 && (num_irq & 32) == 0`, which will lead to error abort. So there is no way to bypass the ```num_irq <= 1020``` check and we cannot use irq number bigger than 992 while in ARM GIC specification, irq number < 1020 should all be aviliable to use. diff --git a/results/classifier/deepseek-2/output/hypervisor/1954 b/results/classifier/deepseek-2/output/hypervisor/1954 new file mode 100644 index 000000000..e55a2133c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1954 @@ -0,0 +1,29 @@ + +guest-fsfreeze can't work well on windows +Description of problem: +I used qemu 5.0 to cross-compile windows gqa on the fedroa30 system.And install it on guest with windows10,but i can't work well. +Steps to reproduce: +1. ./configure --cross-prefix=x86_64-w64-mingw32- --enable-guest-agent-msi --with-vss-sdk=/root/vssdk/VSSSDK72 + + my vssdk download from:[vssdk](https://www.microsoft.com/en-us/download/details.aspx?id=23490),i install it on my pc and copy to /root/vssdk/VSSSDK72 + +2. make qemu-ga -j4 + +3. and then install qemu-ga-x86_64.msi on windows10,it report the error: +  + +4.then I ./configure not with "--with-vss-sdk",the qemu-ga-x86_64.msi can install successfully. + +5.So, I install gga first. Then ./configure with "--with-vss-sdk" to make get the qemu-ga.exe + +6.replace qemu-ga.exe and reboot gga service,then execute the command "virsh domfsfreeze" on host,but it report error: + + error: Unable to freeze filesystems + error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to add \\?\Volume{d1ee1072-0000-0000-0000-100000000000}\ to snapshot set: + + +**I looked at the windows Event Viewer,it get the error:** + + Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. + +I have referred to this [document](https://www.ryadel.com/en/volume-shadow-copy-service-error-unexpected-error-querying-for-the-ivsswritercallback-interface-how-to-fix-that/),but it not work. diff --git a/results/classifier/deepseek-2/output/hypervisor/1958 b/results/classifier/deepseek-2/output/hypervisor/1958 new file mode 100644 index 000000000..5ade3634a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1958 @@ -0,0 +1,22 @@ + +PPC msgsnd for DOORBELL CRITICAL masked by MSR[EE] instead of MSR[CE] +Description of problem: +When executing PPC instruction "msgsnd r3. with r3 = 0x08000001" an DOORBELL CRITICAL exception is raised on core number 1. But this exception is masked by MSR\[EE\] bit, the MSR\[EE\] should be set to 1 in core1 to get this exception. But the NXP E500MCRM.pdf reference manual indicates that MSR\[CE\] is the mask bit for DOORBELL_CRITICAL Exception. +Additional information: +In qemu-8.1.2/target/ppc/excp_helper.c i try to change in ppc_next_unmasked_interrupt_generic function: + +``` +if (FIELD_EX64(env->msr, MSR, CE)) { + /* Critical doorbell */ + if (env->pending_interrupts & PPC_INTERRUPT_CDOORBELL) { <- move this part from (async_deliver != 0) + return PPC_INTERRUPT_CDOORBELL; + } + /* External critical interrupt */ + if (env->pending_interrupts & PPC_INTERRUPT_CEXT) { + return PPC_INTERRUPT_CEXT; + } +} +``` + + +And it seems to work in my case. diff --git a/results/classifier/deepseek-2/output/hypervisor/196 b/results/classifier/deepseek-2/output/hypervisor/196 new file mode 100644 index 000000000..60968a455 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/196 @@ -0,0 +1,2 @@ + +Improve UX for macOS when launching from a fullscreen app diff --git a/results/classifier/deepseek-2/output/hypervisor/1967814 b/results/classifier/deepseek-2/output/hypervisor/1967814 new file mode 100644 index 000000000..a56ec88e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1967814 @@ -0,0 +1,23 @@ + +Ubuntu 20.04.3 - ilzlnx3g1 - virtio-scsi devs on KVM guest having miscompares on disktests when there is a failed path. + +== Comment: #63 - Halil Pasic <email address hidden> - 2022-03-28 17:33:34 == +I'm pretty confident I've figured out what is going on. + +From the guest side, the decision whether the SCSI command was completed successfully or not comes down to looking at the sense data. Prior to commit +a108557bbf ("scsi: inline sg_io_sense_from_errno() into the callers."), we don't +build sense data as a response to seeing a host status presented by the host SCSI stack (e.g. kernel). + +Thus when the kernel tells us that a given SCSI command did not get completed via +SCSI_HOST_TRANSPORT_DISRUPTED or SCSI_HOST_NO_LUN, we end up fooling the guest into believing that the command completed successfully. + +The guest kernel, and especially virtio and multipath are at no fault (AFAIU). Given these facts, it isn't all that surprising, that we end up with corruptions. + +All we have to do is do backports for QEMU (when necessary). I didn't investigate vhost-scsi -- my guess is, that it ain't affected. + +How do we want to handle the back-ports? + +== Comment: #66 - Halil Pasic <email address hidden> - 2022-04-04 05:36:33 == +This is a proposed backport containing 7 patches in mbox format. I tried to pick patches sanely, and all I had to do was basically resolving merge conflicts. + +I have to admit I have no extensive experience in doing such invasive backports, and my knowledge of the QEMU SCSI stack is very limited. I would be happy if the Ubuntu folks would have a good look at this, and if possible improve on it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/1970563 b/results/classifier/deepseek-2/output/hypervisor/1970563 new file mode 100644 index 000000000..bcaf445e6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1974 b/results/classifier/deepseek-2/output/hypervisor/1974 new file mode 100644 index 000000000..11e3fdbd0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1974 @@ -0,0 +1,2 @@ + +Default console changes break Xen command-line diff --git a/results/classifier/deepseek-2/output/hypervisor/1983 b/results/classifier/deepseek-2/output/hypervisor/1983 new file mode 100644 index 000000000..3c4e5690a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1983 @@ -0,0 +1,31 @@ + +Guest boot displays "virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1" and then happens Call Trace +Description of problem: +Guest boot displays "FATAL: Module scsi_wait_scan not found", and then happens Call Trace. + +``` +Call Trace: + dump_stack+0x4f/0x66 + panic+0xa2/0x258 + do_exit+0x858/0xab0 + do_group_exit+0x2f/0x90 + ? do_page_fault+0x18c/0x4c0 + sys_exit_group+0x11/0x20 + do_fast_syscall_32+0x8b/0x1c2 + entry_SYSENTER_32+0xa5/0xf8 +EIP: 0xb7fcec71 +Code: 89 01 31 c0 89 51 04 89 71 08 89 79 0c eb 03 83 c8 ff 83 c4 28 5b 5e 5f 5d c3 8b 1c 24 c3 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76 +EAX: ffffffda EBX: 00000001 ECX: 034c4745 EDX: 00000000 +ESI: 00000000 EDI: 00000000 EBP: bff7db18 ESP: bff7da3c +DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246 +Kernel Offset: 0x16c00000 from 0xc0400000 (relocation range: 0xc0000000-0xf75fdfff) +``` +Steps to reproduce: +1.Create guest by using the command + ``` + ./qemu-system-x86_64 -accel kvm -m 4096 -smp 4 -cpu host -drive file=test-img.qcow2,format=qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -monitor pty -daemonize -vnc :32137 -device virtio-net-pci,netdev=nic0,mac=00:c2:58:38:8e:f0 -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper,vhost=on + ``` +Additional information: +Suspected to be a QEMU regression issue, the first bad commit id: 14f5a7bae4cb5ca45a03e16b5bb0c5d766fd51b7. + +Latest successful version commit id: cea3ea670fe265421131aad90c36fbb87bc4d206 diff --git a/results/classifier/deepseek-2/output/hypervisor/1987 b/results/classifier/deepseek-2/output/hypervisor/1987 new file mode 100644 index 000000000..c64d4139d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1987 @@ -0,0 +1,49 @@ + +snapshot: main thread hangs for a while after 'loadvm' +Description of problem: +When I was testing qemu snapshots, I found that after the `loadvm` command, the virtual machine would often get stuck for a while, and it can **resume execution after I enter some characters into the terminal**, this is weird because my guest system doesn't need to accept input. + +After some debugging, I found that the guest kernel is executing a `wait` instruction in `__r4k_wait()`. + +And I found that the main thread usually does not sleep at `qemu_poll_ns()` during normal execution, but after `loadvm`, the timeout is set to a large value (related to the interval time of snapshot operations), causes the main thread to get stuck on 'qemu_poll_ns()'. + +After some analysis, I think it is because save/load_snapshot() does not handle timers related to QEMU_CLOCK_VIRTUAL well, such as `mips_timer_cb()`, resulting in incorrect value when calculating timeout. +Steps to reproduce: +1. Start emulation and connect monitor +2. `savevm` and wait for a moment +3. `loadvm` +Additional information: +Stack backtrace of the guest kernel: +``` +► 0 0x80104d40 __r4k_wait+32 + 1 0x80143cc4 cpu_startup_entry+284 + 2 0x80143cc4 cpu_startup_entry+284 + 3 0x80143cc4 cpu_startup_entry+284 + 4 0x80633fe0 kernel_init + 5 0x80825cb8 start_kernel+1072 +``` + +Stack backtrace of the main thread: +``` +0 0x7ffff74f0a96 ppoll+166 +1 0x555555ea4786 qemu_poll_ns+221 +2 0x555555e9fea7 os_host_main_loop_wait+93 +3 0x555555e9ffd6 main_loop_wait+187 +4 0x555555a644fd qemu_main_loop+46 +5 0x5555557d2b6a qemu_default_main+17 +6 0x5555557d2ba9 main+45 +7 0x7ffff7402083 __libc_start_main+243 +``` + +Stack backtrace of the vCPU thread: +``` +#0 futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556550848) at ../sysdeps/nptl/futex-internal.h:183 +#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5555564d0860 <qemu_global_mutex>, cond=0x555556550820) at pthread_cond_wait.c:508 +#2 __pthread_cond_wait (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>) at pthread_cond_wait.c:647 +#3 0x0000555555e85602 in qemu_cond_wait_impl (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>, file=0x5555560122ab "../system/cpus.c", line=431) at ../util/qemu-thread-posix.c:225 +#4 0x0000555555a5618f in qemu_wait_io_event (cpu=0x555556825200) at ../system/cpus.c:431 +#5 0x0000555555c8bcf1 in mttcg_cpu_thread_fn (arg=0x555556825200) at ../accel/tcg/tcg-accel-ops-mttcg.c:118 +#6 0x0000555555e85e50 in qemu_thread_start (args=0x555556550860) at ../util/qemu-thread-posix.c:541 +#7 0x00007ffff75d8609 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#8 0x00007ffff74fd133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/1990 b/results/classifier/deepseek-2/output/hypervisor/1990 new file mode 100644 index 000000000..60fdafa76 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1990 @@ -0,0 +1,20 @@ + +qemu ASSERT [ArmCpuDxe] DefaultExceptionHandler.c:333 on Mac M3 +Description of problem: +I am installing Podman 4.7.2 and `podman-machine` uses `qemu-system-aarch64` to boot up an embedded coreos image to run containers. +With the new Apple M3 hardware, I am experiencing a QEMU assertion failure almost all of the time. + + + +`ASSERT [ArmCpuDxe] /home/kraxel/projects/qemu/roms/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(333): ((BOOLEAN)(0==1))` + +I have been unable to get the full crash output - I didn't figure out how to resize the console any larger, and I tried a couple different ways to hook the console up to qemu stdout without any success. (since the kernel command line parameters are not passed in, but instead the image uses a bootloader) + +I believe this is the same issue I experience, but with a better capture of the crash: +https://github.com/lima-vm/lima/issues/1996 +Steps to reproduce: +1. Use Mac M3 (Max in my case) +2. Install Podman +3. Run `podman-machine init` +4. Run `podman-machine start --log-level=debug` +5. Crash (almost certainly) diff --git a/results/classifier/deepseek-2/output/hypervisor/1994002 b/results/classifier/deepseek-2/output/hypervisor/1994002 new file mode 100644 index 000000000..2bf1494eb --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/1999 b/results/classifier/deepseek-2/output/hypervisor/1999 new file mode 100644 index 000000000..43750d5c3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/1999 @@ -0,0 +1,52 @@ + +qemu got sigabrt when using vpp in guest and dpdk for qemu +Description of problem: +When set the interface up in vpp, the qemu process is crashed with signal sigabrt. + +After some debug, i have identified that the problem lies in the following function. + +```c +static int setup_routing_entry(struct kvm *kvm, + struct kvm_irq_routing_table *rt, + struct kvm_kernel_irq_routing_entry *e, + const struct kvm_irq_routing_entry *ue) +{ + struct kvm_kernel_irq_routing_entry *ei; + int r; + u32 gsi = array_index_nospec(ue->gsi, KVM_MAX_IRQ_ROUTES); + + /* + * Do not allow GSI to be mapped to the same irqchip more than once. + * Allow only one to one mapping between GSI and non-irqchip routing. + */ + hlist_for_each_entry(ei, &rt->map[gsi], link) + if (ei->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->u.irqchip.irqchip == ei->irqchip.irqchip) + return -EINVAL; + +``` + +I added some debug printk like following + +```c + hlist_for_each_entry(ei, &rt->map[gsi], link) + if (ei->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->u.irqchip.irqchip == ei->irqchip.irqchip){ + printk("ei->type: %u, KVM_IRQ_ROUTING_IRQCHIP: %u, ue->type: %u, ue->u.irqchip.irqchip: %u , ei->irqchip.irqchip: %u", ei->type, KVM_IRQ_ROUTING_IRQCHIP , ue->type, ue->u.irqchip.irqchip , ei->irqchip.irqchip); + return -EINVAL; + } +``` + +Then i got following in dmesg + +``` +[Thu Nov 23 09:29:10 2023] ei->type: 2, KVM_IRQ_ROUTING_IRQCHIP: 1, ue->type: 1, ue->u.irqchip.irqchip: 2 , ei->irqchip.irqchip: 4276097024 +[Thu Nov 23 09:29:10 2023] ei->type: 2, KVM_IRQ_ROUTING_IRQCHIP: 1, ue->type: 1, ue->u.irqchip.irqchip: 2 , ei->irqchip.irqchip: 4276097024 +``` +Steps to reproduce: +This is a kube-ovn + dpdk env, not easy to reproduce now.. +Additional information: +* I also file a bug on kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=218177 +* the libvirt xml file is also attached [instance.xml](/uploads/05b391046fdc1263fd7e63bcfab6f4fb/instance.xml) diff --git a/results/classifier/deepseek-2/output/hypervisor/2003 b/results/classifier/deepseek-2/output/hypervisor/2003 new file mode 100644 index 000000000..ad2338185 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2003 @@ -0,0 +1,16 @@ + +Windows guest boot happens blue screen and crash by using "-cpu Skylake-Server,+la57,phys-bits=52" +Description of problem: +We are verifying 5-level paging enabling on Windows guest. After creating Windows guest, the system boot caused blue screen and no screen interface response. + +Same QEMU parameter without **+la57,phys-bits=52** (i.e., `./qemu-system-x86_64 -accel kvm -smp 4 -m 4096 -machine q35 -drive file=Winvm5l_host5l_ept5_1698034398,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -cpu Skylake-Server -monitor pty -daemonize -vnc :40541 -device virtio-net-pci,netdev=nic0,mac=00:5b:0b:59:0d:26 -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper,vhost=on`), the same Windows image can be booted successfully. Initially suspected this new QEMU release does not support 5-level paging related features. +Steps to reproduce: +1. Create guest by using the command + +``` +./qemu-system-x86_64 -accel kvm -smp 4 -m 4096 -machine q35 -drive file=Winvm5l_host5l_ept5_1698034398,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -cpu Skylake-Server,+la57,phys-bits=52 -monitor pty -daemonize -vnc :40541 -device virtio-net-pci,netdev=nic0,mac=00:5b:0b:59:0d:26 -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper,vhost=on +``` +Additional information: +Suspected to be a QEMU regression issue, the first bad commit id: 14f5a7bae4cb5ca45a03e16b5bb0c5d766fd51b7. + +Latest successful version commit id: cea3ea670fe265421131aad90c36fbb87bc4d206 diff --git a/results/classifier/deepseek-2/output/hypervisor/2012 b/results/classifier/deepseek-2/output/hypervisor/2012 new file mode 100644 index 000000000..92ac9f9aa --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2012 @@ -0,0 +1,13 @@ + +Possible regression: Windows 95 setup fails on show of license +Description of problem: +Install of Windows 95 fails when showing the license. Qemu v8.1.0 is fine, Qemu 8.1.3 and later failes. Git bisect suggest the problem may have been introduced at 9fb45b05582438dcd52d2d48d48feb05de680c37 +Steps to reproduce: +1. Find install CD for Windows 95 and a DOS boot floppy +2. Create a harddrive (size 300MB) +3. Boot from floppy, create and format partition C: using all available space +4. change to the CD at D: and run command SETUP.EXE +5. follow instructions until display of license +6. See error: SUWIN caused a General Protection Fault in module <unknown> +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2016 b/results/classifier/deepseek-2/output/hypervisor/2016 new file mode 100644 index 000000000..693b58717 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2016 @@ -0,0 +1,10 @@ + +-virtfs not working on windows +Description of problem: +performing the above returns +qemu-system-aarch64.exe: -virtfs abc: There is no option group 'virtfs' +qemu-system-aarch64.exe: -virtfs abc: virtfs support is disabled +Steps to reproduce: +1.qemu-system-aarch64.exe -virtfs abc +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2023 b/results/classifier/deepseek-2/output/hypervisor/2023 new file mode 100644 index 000000000..fca8084bb --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2023 @@ -0,0 +1,2 @@ + +[block jobs]qemu hang when creating snapshot target node(iothread enable) diff --git a/results/classifier/deepseek-2/output/hypervisor/2032 b/results/classifier/deepseek-2/output/hypervisor/2032 new file mode 100644 index 000000000..665a8e91f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2032 @@ -0,0 +1,32 @@ + +qemu-guest-agent not starting +Description of problem: +Trace found in syslog : +``` +syslog:Dec 11 13:45:08 mail systemd[1]: dev-virtio\x2dports-org.qemu.guest_agent.0.device: Job dev-virtio\x2dports-org.qemu.guest_agent.0.device/start timed out. +syslog:Dec 11 13:45:08 mail systemd[1]: Timed out waiting for device /dev/virtio-ports/org.qemu.guest_agent.0. +syslog:Dec 11 13:45:08 mail systemd[1]: qemu-guest-agent.service: Job qemu-guest-agent.service/start failed with result 'dependency'. +syslog:Dec 11 13:45:08 mail systemd[1]: dev-virtio\x2dports-org.qemu.guest_agent.0.device: Job dev-virtio\x2dports-org.qemu.guest_agent.0.device/start failed with result 'timeout'. +``` +Steps to reproduce: +systemctl start qemu-guest-agent +Additional information: +Messages when installing the systemd unit : +``` +systemctl enable qemu-guest-agent +Synchronizing state of qemu-guest-agent.service with SysV service script with /lib/systemd/systemd-sysv-install. +Executing: /lib/systemd/systemd-sysv-install enable qemu-guest-agent +The unit files have no installation config (WantedBy=, RequiredBy=, Also=, +Alias= settings in the [Install] section, and DefaultInstance= for template +units). This means they are not meant to be enabled using systemctl. + +Possible reasons for having this kind of units are: +• A unit may be statically enabled by being symlinked from another unit's + .wants/ or .requires/ directory. +• A unit's purpose may be to act as a helper for some other unit which has + a requirement dependency on it. +• A unit may be started when needed via activation (socket, path, timer, + D-Bus, udev, scripted systemctl call, ...). +• In case of template units, the unit is meant to be enabled with some + instance name specified. + ``` diff --git a/results/classifier/deepseek-2/output/hypervisor/2034 b/results/classifier/deepseek-2/output/hypervisor/2034 new file mode 100644 index 000000000..e0a309c25 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2035 b/results/classifier/deepseek-2/output/hypervisor/2035 new file mode 100644 index 000000000..9009556dd --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2035 @@ -0,0 +1,55 @@ + +TCG Plugin exit callback not executing +Description of problem: +I cannot get the plugin exit callback to register/execute. I should see "Goodbye from plugin" but dont. I have also tried using `qemu_plugin_outs` without success. + +**Update: If I make my test binary an infinite loop and kill it with CTRL-C, then the callback is called as expected. Am I just using it wrong?** +Steps to reproduce: +1. Configured QEMU with `--target-list=riscv32-linux-user,riscv64-linux-user --enable-plugins --disable-system` +2. Compiled plugin with +``` +gcc -I./qemu/include/qemu `pkg-config --libs glib-2.0` -O0 -fvisibility=hidden -Wall -shared -fPIC `pkg-config --cflags glib-2.0` +``` +3. Compiled test binary (just a hello world) with `riscv64-unknown-elf-gcc test_qemu.c -o test_qemu` +4. Ran ./qemu/build/qemu-riscv64 -plugin ./test_plugin.so -d plugin ./test_qemu +Additional information: +test_plugin.c +``` +#include <inttypes.h> +#include <assert.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <stdio.h> +#include <qemu-plugin.h> + +QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) +{ + int n_insns = qemu_plugin_tb_n_insns(tb); + printf("> New TB of size %d\n", n_insns); + + for (int i = 0; i < n_insns; i++) { + struct qemu_plugin_insn * insn = qemu_plugin_tb_get_insn(tb, i); + char * disassembly = qemu_plugin_insn_disas(insn); + printf(" > Instruciton: %s\n", disassembly); + } +} + +static void plugin_exit(qemu_plugin_id_t id, void *p) +{ + printf("> Goodbye from plugin. %d\n", id); +} + +QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id, + const qemu_info_t *info, + int argc, char **argv) +{ + printf("> Hello From Plugin!\n"); + qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans); + qemu_plugin_register_atexit_cb(id, plugin_exit, NULL); + printf("> Everything was registered\n"); + return 0; +} +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/2042 b/results/classifier/deepseek-2/output/hypervisor/2042 new file mode 100644 index 000000000..85e5f9504 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2047 b/results/classifier/deepseek-2/output/hypervisor/2047 new file mode 100644 index 000000000..a0a078b8c --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2055003 b/results/classifier/deepseek-2/output/hypervisor/2055003 new file mode 100644 index 000000000..4be4a194c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2055003 @@ -0,0 +1,66 @@ + +Qemu cmdline core dumped with more(8193 or more) cpus + +---Debugger--- +A debugger is not configured + +---Steps to Reproduce--- + +---Problem Description--- + Qemu cmdline core dumped with more(8193 or more) cpus + +---Debugger--- +A debugger is not configured + +---Steps to Reproduce--- + Qemu cmdline core dumped when more number of CPUs were given. + + +[root@ltcmihawk39 ~]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=9000 +** +ERROR:../tcg/region.c:782:tcg_region_init: assertion failed: (region_size >= 2 * page_size) +Bail out! ERROR:../tcg/region.c:782:tcg_region_init: assertion failed: (region_size >= 2 * page_size) +Aborted (core dumped) + +Expected Result: +Warning message like "Number of cpus requested exceeds the cpus supported" + +Actual Result: +core dumped + +Steps to Reproduce: +-------------------- + +1. Clone the upstream qemu from https://gitlab.com/qemu-project/qemu.git +2. Compile qemu with below steps. + cd qemu/ + git submodule init + git submodule update --recursive + ./configure --target-list=ppc64-softmmu --prefix=/usr + make + make install +3. set maxcpus=8193 or more + + +[root@ltcmihawk39 ~]# qemu-system-ppc64 --version +QEMU emulator version 8.0.94 (v8.1.0-rc4) +Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers + +NOTE: This behavior is observed only when qemu is built without disabling the tcg. + +Contact Information = <email address hidden> + +Machine Type = x + +---uname output--- +x + +Action needed + +Our IBM Dev want to include this patch in latest Canonical distro. + +Need the distro to review and integrate fixes provided by IBM + +https://github.com/qemu/qemu/commit/c4f91d7b7be76c47015521ab0109c6e998a369b0 + +Need to include this commit in latest Canonical distro. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/2063 b/results/classifier/deepseek-2/output/hypervisor/2063 new file mode 100644 index 000000000..08c96c89b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2063 @@ -0,0 +1,56 @@ + +Poor performance with -accel whpx on Server 2022 host, windows 10 guest - missing CPUID hypervisor ident data? +Description of problem: +**Performance of Windows 10 x64 QEMU virtual machine is essentially unusable, compared to same image running under Hyper-V on the same host system.** + +It appears the VM is not being provided the Hyper-V enlightenment hints while running under QEMU. The hv-XXX cpu options do not appear applicable to -accel WHPX. + +Below are dumps of the 0x40000000 cpuid values on the host, QEMU guest, and Hyper-V guest (exact same .VHD file used, nested virtualization not enabled for this VM). + +host: +- 0x40000000 eax=4000000c ebx=7263694d ecx=666f736f edx=76482074 +- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d +- 0x40000003 eax=bfff ebx=2bb9ff ecx=22 edx=71fffbf6 +- 0x40000004 eax=50d1c ebx=fff ecx=0 edx=0 +- 0x40000005 eax=400 ebx=400 ecx=ba00 edx=0 +- 0x40000006 eax=1e00be ebx=0 ecx=0 edx=0 +- 0x40000007 eax=80000007 ebx=3 ecx=0 edx=0 +- 0x40000008 eax=100001 ebx=1 ecx=aaaa edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000c eax=0 ebx=0 ecx=0 edx=0 + +qemu guest with -accel whpx : +- 0x40000000 eax=40000010 ebx=0 ecx=0 edx=0 +- 0x40000001 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000003 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000004 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000005 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000006 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000007 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000008 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000c eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000d eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000e eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000f eax=0 ebx=0 ecx=0 edx=0 +- 0x40000010 eax=225519 ebx=30d40 ecx=0 edx=0 + +hyperv guest VM: (nested virtualization not enabled) +- 0x40000000 eax=4000000b ebx=7263694d ecx=666f736f edx=76482074 +- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d +- 0x40000003 eax=ae7f ebx=388030 ecx=22 edx=e0bed7b2 +- 0x40000004 eax=40c2c ebx=fff ecx=0 edx=0 +- 0x40000005 eax=f0 ebx=400 ecx=ba00 edx=0 +- 0x40000006 eax=e ebx=0 ecx=0 edx=0 +- 0x40000007 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000008 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 diff --git a/results/classifier/deepseek-2/output/hypervisor/2074 b/results/classifier/deepseek-2/output/hypervisor/2074 new file mode 100644 index 000000000..515f25713 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2074 @@ -0,0 +1,21 @@ + +riscv64 cannot use the mret instruction to jump to the address corresponding to s mode +Description of problem: +I use coreboot to boot my linux kernel.The kernel is copied at 0x82200000,I set reg mepc 0x82200000,and set reg mstatus a00000800. +and I use "mret" instruction so that qemu can jump to 0x82200000 and enter S mode.But some errors happened. +It shows: +[DEBUG] Exception: Instruction access fault +[DEBUG] Hart ID: 0 +[DEBUG] Previous mode: machine +[DEBUG] Bad instruction pc: 0x8103f7c0 +[DEBUG] Bad address: 0x00000000 +[DEBUG] Stored ra: 0x8103f7b8 +[DEBUG] Stored sp: 0x82032f08 +Bad instruction pc: 0x8103f7c0 in my elf file instruction is "mret". +So I can not jump to my kernel's load address. +I think when I use -bios option,my qemu should in M mode.How could I can jump to my mepc address? +Steps to reproduce: +1.download qemu +2.download coreboot +Additional information: +When I enter qemu with -bios option,I find that the reg mstatus is 0xa0000000. diff --git a/results/classifier/deepseek-2/output/hypervisor/2077 b/results/classifier/deepseek-2/output/hypervisor/2077 new file mode 100644 index 000000000..4dda063b7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2077 @@ -0,0 +1,2 @@ + +flaky CI test: acpiBitsTest.test_acpi_smbios_bits diff --git a/results/classifier/deepseek-2/output/hypervisor/2078790 b/results/classifier/deepseek-2/output/hypervisor/2078790 new file mode 100644 index 000000000..50d40e2d3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2078790 @@ -0,0 +1,12 @@ + +jammy qemu x86 int3: 0000 [#1] SMP NOPTI + +jammy:linux-lowlatency-hwe-6.8 6.8.0-44.44.1~22.04.1 qemu-x86 QEMU Standard PC (i440FX + PIIX, 1996) + + +Recently (2024.08.05), I have been seeing this issue with ADT:systemd:upstream-1/2 test in which kernel panics/prints a stack. I have seen this with jammy:linux-lowlatency-hwe-6.8 and jammy:linux-ibm-6.8. Stack trace is different everytime because kernel receives an interrupt, drop what it is doing, and crash when handling the interrupt. + +I think this is an issue with qemu and not kernel. For jammy, we are using qemu 6.2 and there are some fixes related to x86 interrupt handling in 8.x (https://<email address hidden>/T/). I propose we create a launchpad bug and trace the issue. If I am correct, we shouldn't see this in noble. And we should occasionally see this in 5.15 jammy kernels (and more frequently with lowlantecy kernels). + + +Meanwhile see comments below for some stack traces; \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/2080 b/results/classifier/deepseek-2/output/hypervisor/2080 new file mode 100644 index 000000000..4cd8d1cb8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2080 @@ -0,0 +1,2 @@ + +CI 'pages' job sometimes fails with "htags: Negative exec line limit" diff --git a/results/classifier/deepseek-2/output/hypervisor/2102 b/results/classifier/deepseek-2/output/hypervisor/2102 new file mode 100644 index 000000000..417c8d0a5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2102 @@ -0,0 +1,41 @@ + +"qemu-img resize -f qcow2" produces broken disk images +Description of problem: +The documentation of `qemu-img` at +<https://www.qemu.org/docs/master/tools/qemu-img.html> +makes it sound like `qemu-img resize` supports various image formats +(raw, qcow2, etc.) in the same way. + +But it doesn't. While `qemu-img resize -f raw` works as expected, +`qemu-img resize -f qcow2` produces broken disk images. +Steps to reproduce: +``` +$ wget http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz +$ gunzip arm64.img +``` + +First resize, then convert: +``` +$ cp arm64.img arm64-rc.img +$ qemu-img resize -f raw arm64-rc.img 10G +$ qemu-img convert -f raw -O qcow2 arm64-rc.img arm64-rc.qcow2 +$ rm -f arm64-rc.img +``` + +First convert, then resize: +``` +$ qemu-img convert -f raw -O qcow2 arm64.img arm64-cr.qcow2 +$ qemu-img resize -f qcow2 arm64-cr.qcow2 10G +``` + +Attach to a VM in VirtualBox (as an additional SATA disk) and start that VM. + +arm64-rc.qcow2 => +`# fdisk /dev/sdb` => it has two partitions. + +arm64-cr.qcow2 => +`# fdisk /dev/sdb` => it has no partitions! +And the VM cannot be cleanly shut down. I had to manually kill the VirtualBoxVM +process. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2108 b/results/classifier/deepseek-2/output/hypervisor/2108 new file mode 100644 index 000000000..2f07be521 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2108 @@ -0,0 +1,2 @@ + +ppc64 POWER10 machine-check caused by ifetch crashes qemu diff --git a/results/classifier/deepseek-2/output/hypervisor/2115 b/results/classifier/deepseek-2/output/hypervisor/2115 new file mode 100644 index 000000000..385fc15b6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2124 b/results/classifier/deepseek-2/output/hypervisor/2124 new file mode 100644 index 000000000..496d81661 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2124 @@ -0,0 +1,2 @@ + +Use watchdog_perform_action() for watchdogs currently using qemu_system_reset_request() diff --git a/results/classifier/deepseek-2/output/hypervisor/2142 b/results/classifier/deepseek-2/output/hypervisor/2142 new file mode 100644 index 000000000..d26433544 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2142 @@ -0,0 +1,2 @@ + +`-machine microvm -cpu host` crashes when guest attempts to check CPUID SGX bits diff --git a/results/classifier/deepseek-2/output/hypervisor/215 b/results/classifier/deepseek-2/output/hypervisor/215 new file mode 100644 index 000000000..a0437373b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/215 @@ -0,0 +1,2 @@ + +x86 Floating point exceptions - incorrect support? diff --git a/results/classifier/deepseek-2/output/hypervisor/216 b/results/classifier/deepseek-2/output/hypervisor/216 new file mode 100644 index 000000000..86f6a31df --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/216 @@ -0,0 +1,2 @@ + +qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic - kernel: no nucleus hblk8 to allocate" diff --git a/results/classifier/deepseek-2/output/hypervisor/2163 b/results/classifier/deepseek-2/output/hypervisor/2163 new file mode 100644 index 000000000..d5b6c5594 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2163 @@ -0,0 +1,2 @@ + +Move architecture specific interruption code around SPARC CPUs from hw/sparc/ to target/sparc/ diff --git a/results/classifier/deepseek-2/output/hypervisor/2166 b/results/classifier/deepseek-2/output/hypervisor/2166 new file mode 100644 index 000000000..b8f5d7923 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2166 @@ -0,0 +1,2 @@ + +RISC-V qemu has bug on the return value of function qemu_plugin_mem_size_shift() diff --git a/results/classifier/deepseek-2/output/hypervisor/2168 b/results/classifier/deepseek-2/output/hypervisor/2168 new file mode 100644 index 000000000..0a27e95d8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2168 @@ -0,0 +1,33 @@ + +qemu-x86_64: segfault when running grep on arm64 host +Description of problem: +An internal segmentation fault occurs when attempting to run `grep` in a Gentoo stage3 chroot +Steps to reproduce: +1. Unpack an x86_64 chroot environment (easiest way is using one of Gentoo's stage3s from https://get.gentoo.org) +2. Run `qemu-x86_64 -L /path/to/x86_64/chroot /path/to/x86_64/chroot/bin/grep` +Additional information: +It seems this only occurs in 8.x.x, 7.x.x does not have this segfault. + +Output: +``` +# qemu-x86_64 -L /bugs/grep-sandbox /bugs/grep-sandbox/bin/grep +qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault +``` + +GDB bt: +``` +(gdb) bt +#0 open_self_maps_2 (opaque=0xffffffffd0b0, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089 +#1 0x000000000048539c in walk_memory_regions (priv=priv@entry=0xffffffffd0b0, fn=fn@entry=0x4a13e4 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176 +#2 0x00000000004a20bc in open_self_maps_1 (smaps=false, fd=3, env=<optimized out>) at ../linux-user/syscall.c:8112 +#3 open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122 +#4 0x00000000004aaa00 in do_guest_openat (cpu_env=cpu_env@entry=0x862050, dirfd=dirfd@entry=-100, fname=fname@entry=0x5555555776f1 "/proc/self/maps", flags=0, mode=mode@entry=0, safe=safe@entry=true) + at ../linux-user/syscall.c:8381 +#5 0x00000000004b0cc4 in do_syscall1 (cpu_env=cpu_env@entry=0x862050, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=93824992376561, arg3=arg3@entry=0, arg4=arg4@entry=0, + arg5=arg5@entry=93824992373306, arg6=arg6@entry=0, arg8=0, arg7=0) at ../linux-user/syscall.c:9075 +#6 0x00000000004b2770 in do_syscall (cpu_env=cpu_env@entry=0x862050, num=257, arg1=4294967196, arg2=93824992376561, arg3=0, arg4=0, arg5=93824992373306, arg6=0, arg7=arg7@entry=0, arg8=arg8@entry=0) + at ../linux-user/syscall.c:13658 +#7 0x0000000000404fdc in cpu_loop (env=env@entry=0x862050) at ../linux-user/x86_64/../i386/cpu_loop.c:242 +#8 0x0000000000400d7c in main (argc=4, argv=0xffffffffed48, envp=<optimized out>) at ../linux-user/main.c:1014 +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/217 b/results/classifier/deepseek-2/output/hypervisor/217 new file mode 100644 index 000000000..d538d0a20 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/217 @@ -0,0 +1,2 @@ + +Qemu does not force SSE data alignment diff --git a/results/classifier/deepseek-2/output/hypervisor/2173 b/results/classifier/deepseek-2/output/hypervisor/2173 new file mode 100644 index 000000000..2268aef99 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2174 b/results/classifier/deepseek-2/output/hypervisor/2174 new file mode 100644 index 000000000..fae96e123 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2174 @@ -0,0 +1,2 @@ + +XenBus machines have almost no hotplug support diff --git a/results/classifier/deepseek-2/output/hypervisor/2180 b/results/classifier/deepseek-2/output/hypervisor/2180 new file mode 100644 index 000000000..aa95b7d48 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2180 @@ -0,0 +1,37 @@ + +QEMU crashes when an interrupt is triggered whose descriptor is not in physical memory +Description of problem: +When an interrupt is triggered whose descriptor is mapped but not in physical memory, QEMU crashes with the following message: +``` +** +ERROR:../system/cpus.c:524:bql_lock_impl: assertion failed: (!bql_locked()) +Bail out! ERROR:../system/cpus.c:524:bql_lock_impl: assertion failed: (!bql_locked()) +Aborted (core dumped) +``` + +The given code triggers the bug by moving the IDT's base address, but it can also be triggered by any other method of moving the IDT's physical memory location, f.ex paging. With KVM enabled, this specific example loops forever instead of crashing, but if the code is altered to use paging, an internal KVM error is reported and the VM is paused. +Steps to reproduce: +1. Assemble the code listed below using NASM: `nasm test.asm -o test.bin` +2. Run the code using `qemu-system-i386 -drive format=raw,file=test.bin`. Note that the given code only triggers the bug if the guest has 2 gigabytes or less of physical memory. +3. QEMU crashes. +Additional information: +NASM assembly of the code used: +``` +bits 16 +org 0x7c00 + +_start: + ; Disable interrupts and load new IDT + cli + o32 lidt [idtdesc] + ; Descriptor for INT 0 is in nonexistent physical memory, which crashes QEMU. + int 0x00 + +idtdesc: + dw 0x3ff ; Limit: 1 KiB for IDT + dd 0x80000000 ; Base: 2 GiB + +; Like most BIOSes, SeaBIOS requires this magic number to boot +times 510-($-$$) db 0 +dw 0xaa55 +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/2187 b/results/classifier/deepseek-2/output/hypervisor/2187 new file mode 100644 index 000000000..7f6c167a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2187 @@ -0,0 +1,2 @@ + +system/cpu: deadlock in pause_all_vcpus() diff --git a/results/classifier/deepseek-2/output/hypervisor/2195 b/results/classifier/deepseek-2/output/hypervisor/2195 new file mode 100644 index 000000000..f921febd8 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2205 b/results/classifier/deepseek-2/output/hypervisor/2205 new file mode 100644 index 000000000..010d3e81a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2205 @@ -0,0 +1,51 @@ + +9p rootfs issues +Description of problem: +I've created qemu guest per https://wiki.qemu.org/Documentation/9p_root_fs guidelines. debootstrap fails on this guest. +Steps to reproduce: +``` +root@ubuntu-dev:~# debootstrap --arch amd64 --variant=minbase noble /var/tmp/new_root/ +I: Retrieving InRelease +I: Checking Release signature +E: Error executing gpgv to check Release signature +root@ubuntu-dev:~# +``` +Additional information: +I noticed, that gpg key extracted by debootstrap from the InRelease is corrupted: +``` +root@ubuntu-dev:~# head /var/tmp/new_root/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_noble_Release.gpg +-----BEGIN PGP SIGNATURE----- +-----BEGIN PGP SIGNATURE----- + +-----BEGIN PGP SIGNATURE----- +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCgAdFiEE9uyzdiR07anSG3Aihxkg0ZkbyTwFAmXkbkUACgkQhxkg0Zkb +-----BEGIN PGP SIGNATURE----- +-----BEGIN PGP SIGNATURE----- + +root@ubuntu-dev:~# +``` +I also noticed that on the 9p filesystem appending to files corrupts them: +``` +root@ubuntu-dev:~# echo 1 >/var/tmp/test +root@ubuntu-dev:~# cat /var/tmp/test +1 +root@ubuntu-dev:~# echo 2 >>/var/tmp/test +root@ubuntu-dev:~# cat /var/tmp/test +1 +1 +2 +root@ubuntu-dev:~# +``` +This is not happening on the tmpfs: +``` +root@ubuntu-dev:~# echo 1 >/tmp/test +root@ubuntu-dev:~# cat /tmp/test +1 +root@ubuntu-dev:~# echo 2 >>/tmp/test +root@ubuntu-dev:~# cat /tmp/test +1 +2 +root@ubuntu-dev:~# +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/2226 b/results/classifier/deepseek-2/output/hypervisor/2226 new file mode 100644 index 000000000..e9ccac292 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/223 b/results/classifier/deepseek-2/output/hypervisor/223 new file mode 100644 index 000000000..a6c4b974b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/223 @@ -0,0 +1,2 @@ + +guest migration 100% cpu freeze bug diff --git a/results/classifier/deepseek-2/output/hypervisor/2241 b/results/classifier/deepseek-2/output/hypervisor/2241 new file mode 100644 index 000000000..a929b7f4b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2241 @@ -0,0 +1,2 @@ + +QMP Commands dont't work properly diff --git a/results/classifier/deepseek-2/output/hypervisor/2242 b/results/classifier/deepseek-2/output/hypervisor/2242 new file mode 100644 index 000000000..c5c43e073 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2242 @@ -0,0 +1,15 @@ + +Hugepages are not released after windows guest shutdown +Description of problem: +* Hugepages are not released after windows guest shutdown (tested with server 2019 and 2022), everything is ok with linux guests +* Issue is present in both cases: shutdown is initiated by guest, and with the qemu monitor command ``system_shutdown`` +* If the guest is configured with 4G as memory size, hugepages not released may vary but in most cases, only 1G are not released +* Host is a x86_64 linux system, with 1G hugepages only : kernel cmline contains ``default_hugepagesz=1G hugepagesz=1G hugepages=88`` +* I've done many tests with qemu components disabled (network, monitor, vnc), issue is still present with basic command line (launched as root) ``qemu-system-x86_64 -cpu host -enable-kvm -smp 4 -machine type=q35,accel=kvm -m 4G -mem-path /mnt/hugepages -drive id=drv0,file=win.qcow2 -nodefaults`` +* Same issue with args in command line, with or without prealloc: + + -m 4G -mem-path /mnt/hugepages [-mem-prealloc] + -m 4G -machine memory-backend=mem0 -object memory-backend-memfd,id=mem0,size=4G,hugetlb=on,hugetlbsize=1G[,prealloc=on] +Additional information: +* Hugepages release process is audited with command ``cat /proc/meminfo`` +* I can't find any online documentation to help to troubleshoot used hugepages : articles suggest to audit /proc/[pid]/smaps, but here, issue is raised after qemu process terminates diff --git a/results/classifier/deepseek-2/output/hypervisor/2245 b/results/classifier/deepseek-2/output/hypervisor/2245 new file mode 100644 index 000000000..dc90dd981 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2245 @@ -0,0 +1,2 @@ + +RISC-V Extensions query for QEMU System diff --git a/results/classifier/deepseek-2/output/hypervisor/2246 b/results/classifier/deepseek-2/output/hypervisor/2246 new file mode 100644 index 000000000..456a90442 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2250 b/results/classifier/deepseek-2/output/hypervisor/2250 new file mode 100644 index 000000000..a65326543 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2250 @@ -0,0 +1,45 @@ + +FEAT_RME: NS EL1/0 Address Translation from EL3 fails +Description of problem: +I'm playing around with the QEMU RME Stack (TF-A, TF-RMM, Linux/KVM) for a research project. +For this I want to access some virtual normal world memory address from within EL3. +To translate the address to the physical address I use the `AT` instructions (e.g., `ats1e2r`). +If the NW memory is initially mapped in the GPT as `GPT_GPI_ANY`, this works fine, however, if the NW memory is mapped as `GPT_GPI_NS` the address translation fails with the error `0b100101`/GPT on PTW. +However, EL3/Root World should be able to access memory from all PAS, and therefore, if I understand the ARM documentation correctly, should also be able to execute a PTW for an address marked NS in the GPT. +Steps to reproduce: +1. Setup GPT with some memory marked as `GPT_GPI_NS` +2. Forward some NW virtual address from the kernel to EL3 +3. Execute a PTW on this address via the `AT` instructions. +Additional information: +I also took a look into the QEMU source code and potentially found the issue. +When executing a PTW we execute `target/arm/ptw.c:granule_protection_check`. +The function extracts the target page's GPI (`ptw.c:440'): +```c + switch (gpi) { + case 0b0000: /* no access */ + break; + case 0b1111: /* all access */ + return true; + case 0b1000: + case 0b1001: + case 0b1010: + case 0b1011: + if (pspace == (gpi & 3)) { + return true; + } + break; + default: + goto fault_walk; /* reserved */ + } +``` +The if statement checks if the current `pstate` (previously set to `ptw->in_space`) is the same security state as the one contained in the GPI. +If this is not the case, we generate a GPF. +However, I think the code misses the fact, that EL3/Root world can access memory from each PAS, meaning that the if statement should be something like +```c +if (pspace == (gpi & 3) || (pspace == ARMSS_Root)) { + return true; +} +``` +Additionally, as both Secure and Realm World can also access Normal World memory, similar checks should also be added in such cases. + +I have a patch prepared for this, however, I first want to check in if I'm in line with the Arm ARM or if I'm missing something and EL3 is indeed not supposed to execute PTWs for NS memory. diff --git a/results/classifier/deepseek-2/output/hypervisor/2251 b/results/classifier/deepseek-2/output/hypervisor/2251 new file mode 100644 index 000000000..1b09eb783 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2251 @@ -0,0 +1,15 @@ + +Windows 11 VM with VBS enabled crashes +Description of problem: + +Steps to reproduce: +1. Run a Windows 11 VM on a node (both VM domain XML and node capabilities XML is provided below). +2. Enable VBS on the guest. For doing so you can use https://github.com/MicrosoftDocs/windows-itpro-docs/files/4020040/DG_Readinessv3.7.zip. Then, in Windows terminal, run DG_Readiness_Tool_{version}.ps1 -Enable. +3. Reboot the guest. +4. Windows cannot start (see picture below). +Additional information: +- Domain Capabilities: https://pastebin.com/GdQGQ639 +- VMX capabilities: https://pastebin.com/5nbUH0ev +- contents of /proc/cpuinfo: https://pastebin.com/xZM4x89z +- Domain XML: https://pastebin.com/s4VehTXK +- Windows crash at boot: https://ibb.co/Ny1xRbz diff --git a/results/classifier/deepseek-2/output/hypervisor/2258 b/results/classifier/deepseek-2/output/hypervisor/2258 new file mode 100644 index 000000000..4172c8173 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2258 @@ -0,0 +1,24 @@ + +Breakpoint setting not working on apple Mac host +Description of problem: +1. When use with parameter "-machine virt,accel=hvf -cpu host" to run launch a emulator, it can't set breakpoint and will report error: "warning: failed to set breakpoint site at 0xffff800081bf03cc for breakpoint 1.1: error: 34 sending the breakpoint request" +but if not use with parameter "-machine virt -cpu cortex-a57"，The breakpoint can be set successfully. + +2. Set hardware breakpoint with lldb command "breakpoint set -H -a 0xFFFF800080000000" not report error, but can't hint breakpoint. I try set breakpoint on a old x86 MacOS, It will hint breakpoint successfully. + +3. I also try run qemu-system-x86_64 emulator on apple silicon mac, It also can't hint hardware breakping. The command is: +``` +qemu-system-x86_64 -machine q35,accel=tcg -smp cpus=8 \ + -kernel arch/x86/boot/bzImage \ + -append "okaslr"\ + -nographic -serial mon:stdio \ + -m 16G \ + -s -S +``` +Steps to reproduce: +1. Launch qemu on Apple silicon Mac. Remember to user "hvf" +2. Launch lldb or gdb to set breakpoint. +3. Set breakpoint and hardware breakpoint. +4. resume to run qemu by lldb. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2259 b/results/classifier/deepseek-2/output/hypervisor/2259 new file mode 100644 index 000000000..82d315c4a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2259 @@ -0,0 +1,15 @@ + +The cause code of a trap changes when qemu is nested in another qemu +Description of problem: +I am studying the feasibility of doing some practical work on RISCV plates. Since I don't have these boards yet, I'm emulating it with qemu. The practice in turn consists of launching with qemu a very small operating system with two tasks that make a series of system calls. + +When I run this practice on my host it works correctly, but when I run it on an Ubuntu emulated in riscv with qemu, the cause code for the trap changes (the first bit of the code). + +The demo can be found in this repository: https://github.com/Sft570/qemu-bug-report +Steps to reproduce: +1. Clone the repository on the host and run the demo with "make qemu" +2. Emulate with qemu ubuntu in riscv, clone the repository and run the demo with "make qemu". + +The error displayed shows the change of the cause code bit. You can analyze its behavior in the trap.c file in the src folder. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2263 b/results/classifier/deepseek-2/output/hypervisor/2263 new file mode 100644 index 000000000..f13dc177b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2263 @@ -0,0 +1,29 @@ + +guest panics when attempting to perform loadvm operation on x86_64 platform with kvm_intel ept=0 +Description of problem: +The guest experiences a panic when attempting to perform the `loadvm` operation after it has been running for a while on the x86_64 platform with `kvm_intel ept=0`. I'm unsure if this operation is permitted or not, but it functions properly when using `kvm_intel ept=1`. +Steps to reproduce: +1. Load the `kvm-intel` module with the parameter `ept=0`. +2. savevm +Boot the first guest using the previous command line and switch to the QEMU console to execute the `savevm` operation. After that, proceed to shutting down the guest. +3. loadvm +Boot the second guest using the same command line and switch to the QEMU console to execute the `loadevm` operation. After that, the guest panics. +Additional information: +I have performed some debugging and it seems that the issue lies in the fact that the VMM modifies the guest memory without informing the KVM module. Upon further investigation, I noticed that the `loadvm` operation only restores the memory and does not execute any ioctl to modify the user memory region recorded in the KVM module. + +The KVM module calls `kvm_mmu_reset_context()` to unload the current EPT or SPT page table when guest system registers (CR0/CR3/CR4) are restored. However, for EPT, the EPT page table is released directly and can be reconstructed at a later stage. In contrast, for SPT, the KVM only decreases the reference count and retains the outdated SPT page table in the active list that is maintained by the KVM. As a result, this outdated SPT page table is reused later, leading to incorrect mapping. + +To address this, I attempted to call `kvm_arch_flush_shadow_all()` to zap all the page tables in `kvm_mmu_reset_context()`, which allowed the guest to function properly with SPT after the `loadvm` operation. + +Therefore, I believe that QEMU should notify the KVM to clear all the page tables if the KVM is using shadow paging. However, it appears that there is no appropriate ioctl available for the VMM to achieve this. + +guest panic output: + + +Trace the `kvm_mmu_get_page()` event and observe that only one record indicates that the outdated page table is reused instead of being recreated. + + +```shell +perf record -a -e kvmmmu:kvm_mmu_get_page +``` + diff --git a/results/classifier/deepseek-2/output/hypervisor/2270 b/results/classifier/deepseek-2/output/hypervisor/2270 new file mode 100644 index 000000000..e4992dcc1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2270 @@ -0,0 +1,2 @@ + +CPU topology recognition for Ryzen 9 7950X3D diff --git a/results/classifier/deepseek-2/output/hypervisor/2277 b/results/classifier/deepseek-2/output/hypervisor/2277 new file mode 100644 index 000000000..a2207ddea --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2277 @@ -0,0 +1,2 @@ + +COarse-grained LOck-stepping Virtual Machines for Non-stop Service Encountered Assertion Error diff --git a/results/classifier/deepseek-2/output/hypervisor/2287 b/results/classifier/deepseek-2/output/hypervisor/2287 new file mode 100644 index 000000000..2973051f8 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2294 b/results/classifier/deepseek-2/output/hypervisor/2294 new file mode 100644 index 000000000..e0b19d459 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2294 @@ -0,0 +1,2 @@ + +x86 microvm machine stuck under Xen accelerator diff --git a/results/classifier/deepseek-2/output/hypervisor/2295 b/results/classifier/deepseek-2/output/hypervisor/2295 new file mode 100644 index 000000000..d5fa3e915 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2311 b/results/classifier/deepseek-2/output/hypervisor/2311 new file mode 100644 index 000000000..067d56b2a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2311 @@ -0,0 +1,16 @@ + +Possible dereference of NULL +Description of problem: +There is possible dereference of NULL using macro QEMU_LOCK_GUARD(&q->lock) in: +1) /block/nvme.c line [326](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/block/nvme.c#L326) +2) /include/qemu/ratelimit.h line [45](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L45) +3) /include/qemu/ratelimit.h line [88](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L88) + + +The QEMU_MAKE_LOCKABLE(x) macro provides a special case (line [71](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L71) of the lockable.h) if NULL gets into it. Then the macro will return NULL, which will get to the input of the qemu_lockable_auto_lock() function, then to the qemu_lockable_lock() function, where NULL dereference will occur (line [95](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L95)). + +It turns out that the NULL case is provided, but not handled properly. I think a NULL check should be added. + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Burke. diff --git a/results/classifier/deepseek-2/output/hypervisor/2313 b/results/classifier/deepseek-2/output/hypervisor/2313 new file mode 100644 index 000000000..d83f9b9f2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2313 @@ -0,0 +1,18 @@ + +RISC-V KVM strerrorname_np regression breaks build on Alpine Linux +Description of problem: +Build from source fails on Alpine Linux due to the use of the non-portable `strerrorname_np`: +``` +/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_realize': +kvm-cpu.c:(.text+0x538): undefined reference to `strerrorname_np' +/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_instance_init': +kvm-cpu.c:(.text+0x1244): undefined reference to `strerrorname_np' +``` +Steps to reproduce: +1. install alpine linux on a riscv64 machine +2. build qemu-9.0.0 from source. +3. +Additional information: +Same problem as https://gitlab.com/qemu-project/qemu/-/issues/2041 + +Re-introduced with d4ff3da8f45c52670941c6e1b94e771d69d887e9 and 0d71f0a34938a6ac11953ae3dbec40113d2838a1 diff --git a/results/classifier/deepseek-2/output/hypervisor/2324 b/results/classifier/deepseek-2/output/hypervisor/2324 new file mode 100644 index 000000000..90eb4a6ad --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2324 @@ -0,0 +1,48 @@ + +SELinux is preventing some qemu-kvm operations on CentOS Stream 9 +Description of problem: +Some operations are being denied by SELinux. + +First it was read access on file max_map_count, then open and getattr access on /proc/sys/vm/max_map_count (same file but with full path). + +All have been fixed by creating and applying a semodule with the TE policy shown on "Additional Information" below. + +``` +May 2 18:01:00 rd02 setroubleshoot[14757]: SELinux is preventing /usr/libexec/qemu-kvm from read access on the file max_map_count. For complete SELinux messages run: sealert -l c92d5506-0b40-4bc8-be6a-133fe360014d +May 2 18:01:00 rd02 setroubleshoot[14757]: SELinux is preventing /usr/libexec/qemu-kvm from read access on the file max_map_count.#012#012***** Plugin qemu_file_image (98.8 confidence) suggests *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t 'max_map_count'#012# restorecon -v 'max_map_count'#012#012***** Plugin catchall (2.13 confidence) suggests **************************#012#012If you believe that qemu-kvm should be allowed read access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012 + +--- + +May 3 10:24:58 rd02 setroubleshoot[3981]: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /proc/sys/vm/max_map_count. For complete SELinux messages run: sealert -l 655af27c-6bc7-4278-9aad-7fc99929d24b +May 3 10:24:58 rd02 setroubleshoot[3981]: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /proc/sys/vm/max_map_count.#012#012***** Plugin qemu_file_image (98.8 confidence) suggests *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t '/proc/sys/vm/max_map_count'#012# restorecon -v '/proc/sys/vm/max_map_count'#012#012***** Plugin catchall (2.13 confidence) suggests **************************#012#012If you believe that qemu-kvm should be allowed open access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012 + +--- + +May 3 10:41:17 rd02 setroubleshoot[6894]: SELinux is preventing /usr/libexec/qemu-kvm from getattr access on the file /proc/sys/vm/max_map_count. For complete SELinux messages run: sealert -l db78c5b9-3890-44d4-a40e-d4011ad42913 +May 3 10:41:17 rd02 setroubleshoot[6894]: SELinux is preventing /usr/libexec/qemu-kvm from getattr access on the file /proc/sys/vm/max_map_count.#012#012***** Plugin qemu_file_image (98.8 confidence) suggests *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t '/proc/sys/vm/max_map_count'#012# restorecon -v '/proc/sys/vm/max_map_count'#012#012***** Plugin catchall (2.13 confidence) suggests **************************#012#012If you believe that qemu-kvm should be allowed getattr access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012 + + +``` +Steps to reproduce: +1. On a CentOS Stream 9 system with a selinux enforced, create a VM and install an OS with cockpit or with virt-install. + - example with virt-install: + `virt-install --connect qemu:///system --os-variant centos-stream9 --reinstall ipa03 --wait -1 --location /mnt/CentOS-Stream9.iso` +2. Check the SELinux logs, either on cockpit or on /var/log/messages +Additional information: +TE module that solved the issue, created with `ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm` + +``` +module my-qemukvm 1.1; + +require { + type sysctl_vm_t; + type svirt_t; + class file { getattr open read }; +} + +#============= svirt_t ============== + +#!!!! This avc is allowed in the current policy +allow svirt_t sysctl_vm_t:file read; +allow svirt_t sysctl_vm_t:file { getattr open }; +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/233 b/results/classifier/deepseek-2/output/hypervisor/233 new file mode 100644 index 000000000..26aad6844 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/233 @@ -0,0 +1,2 @@ + +QEMU installer with WHPX support diff --git a/results/classifier/deepseek-2/output/hypervisor/2343 b/results/classifier/deepseek-2/output/hypervisor/2343 new file mode 100644 index 000000000..44da65d48 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2343 @@ -0,0 +1,32 @@ + +pflash write timeout u-boot@qemu-system-aarch64 +Description of problem: +Emulating the write into flash of environment variables within U-boot is not possible anymore. This works natively in Fedora 39 which has the 8.1.3 qemu version. Stopped working after transitioning to Fedora 40 which currently comes with 8.2.2, also doesn't work with Debian 12 which has 7.2.9. + +The write fails with the following message: + +``` +=> saveenv +Saving Environment to Flash... Un-Protected 2 sectors +Erasing Flash... +.. done +Erased 2 sectors +Writing to Flash... pflash_write: Write to buffer emulation is flawed +pflash_write: Write to buffer emulation is flawed +pflash_write: Write to buffer emulation is flawed +Flash buffer write timeout at address 4000000 data ffffffffb64f6361 +Timeout writing to Flash +Protected 2 sectors +Failed (1) +``` +Steps to reproduce: +1. Download or build u-boot for aarch64 qemu. You can extract from u-boot-qemu debian package https://packages.debian.org/unstable/u-boot-qemu . +2. `truncate -s 64m varstore.img` +3. `qemu-system-aarch64 -machine virt -cpu cortex-a35 -nographic -smp 2 -m 1G -bios u-boot.bin -drive if=pflash,format=raw,file=varstore.img,readonly=off,index=1 -d guest_errors,unimp` +Additional information: +After building versions 8.1.3 and 8.1.4 I found both were working fine regartheless the host OS, the issue was introduced in 8.1.5. +After inspecting commits history I drop the following commit [hw/pflash: implement update buffer for block writes (hash:fcc79f2e09550b0461792491965fe202ed2219ae)](https://gitlab.com/qemu-project/qemu/-/commit/fcc79f2e09550b0461792491965fe202ed2219ae) rebuilt and the issue was gone. +I then recheck all non working versions and both versions 8.2.2 and 7.2.9 also have this commit, this explains why it also doesn't work. +I attached a trace running with v8.1.5 and v8.1.5 with drop commit. +[v8.1.5.log](/uploads/04aa0e24e1e16f6bdf29a6e6be587ba1/v8.1.5.log) +[v8.1.5-drop-fcc79f2e.log](/uploads/206fe958ab78c12542fda3764df978da/v8.1.5-drop-fcc79f2e.log) diff --git a/results/classifier/deepseek-2/output/hypervisor/2354 b/results/classifier/deepseek-2/output/hypervisor/2354 new file mode 100644 index 000000000..139a29c8c --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2360 b/results/classifier/deepseek-2/output/hypervisor/2360 new file mode 100644 index 000000000..40a5de2a9 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2360 @@ -0,0 +1,31 @@ + +qemu-system-m68k: double mmu fault +Description of problem: +Shutting down Mac OS 7.5.3 after boot from CD image results in a double MMU fault. +qemu: fatal: DOUBLE MMU FAULT + +D0 = 00000008 A0 = 22152a78 F0 = 7fff ffffffffffffffff ( nan)\ +D1 = 40810000 A1 = 0000c190 F1 = 7fff ffffffffffffffff ( nan)\ +D2 = 00010490 A2 = 000207a0 F2 = 7fff ffffffffffffffff ( nan)\ +D3 = 0002befe A3 = a88879d0 F3 = 7fff ffffffffffffffff ( nan)\ +D4 = db6d0000 A4 = 00041a86 F4 = 7fff ffffffffffffffff ( nan)\ +D5 = 00000000 A5 = 39ec4080 F5 = 7fff ffffffffffffffff ( nan)\ +D6 = 00000001 A6 = 00053178 F6 = 7fff ffffffffffffffff ( nan)\ +D7 = 07b6d258 A7 = 00000004 F7 = 7fff ffffffffffffffff ( nan)\ + +PC = 97f87008 SR = 2210 T:0 I:2 SI X---- \ +FPSR = 00000000 ---- \ +FPCR = 0000 X RN \ +A7(MSP) = 00000000 A7(USP) = 00000000 ->A7(ISP) = 00000004 \ +VBR = 0x00000000 \ +SFC = 0 DFC 5 \ +SSW 00000505 TCR 0000c000 URP 00000000 SRP 07fffa00 \ +DTTR0/1: f900c060/807fc040 ITTR0/1: f900c060/807fc040 \ +MMUSR 00000000, fault at fffffffc \ +Steps to reproduce: +1. Boot from CD image +2. Choose Shut down from the Special menu +Additional information: +Reproducing requires a quadra 800 rom file.\ +A CD image (f.e. SYSTEM_7-5-3-RETAIL.ISO) can be obtained here: https://macintoshgarden.org/apps/macintosh-os-755 \ +Also see here: https://gitlab.com/qemu-project/qemu/-/issues/2249 diff --git a/results/classifier/deepseek-2/output/hypervisor/2367 b/results/classifier/deepseek-2/output/hypervisor/2367 new file mode 100644 index 000000000..a2288a981 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2367 @@ -0,0 +1,2 @@ + +qemu8.2 check test failed diff --git a/results/classifier/deepseek-2/output/hypervisor/2383 b/results/classifier/deepseek-2/output/hypervisor/2383 new file mode 100644 index 000000000..2a8582068 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2383 @@ -0,0 +1,4 @@ + +Support SMRR for x86 emulation +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2385 b/results/classifier/deepseek-2/output/hypervisor/2385 new file mode 100644 index 000000000..b6b185ed2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2385 @@ -0,0 +1,108 @@ + +sparc: SIGILL stepping over `std` in gdb +Description of problem: +Certain cases of single-stepping thru the `std` store double-word instruction causes SIGILL fatal trap, while normal execution of the program is fine. Unfortunately I do not have access to real SPARC hardware so I cannot attest whether this is an emulation issue or not. + +My previous bugfix #2281 fixed any single-stepping in a debugger from panicking the kernel, associated with the `lda` on ASI_USERTXT in the `default_fuword32` function. I suspect further bugs like this could be related somehow. Perhaps a different instruction is used for the 64-bit access that needs a similar fix. + +This problem was experienced while testing some shell-spawning assembly: +``` +-bash-4.3$ cat test.s +.section ".text" +.global main +main: + sethi %hi(0x2f626800), %l6 + or %l6, 0x16e, %l6 ! 0x2f62696e + sethi %hi(0x2f6b7000), %l7 + or %l7, 0x368, %l7 ! 0x2f6b7368 + and %sp, %sp, %o0 + add %sp, 0xc, %o1 + xor %o2, %o2, %o2 + add %sp, 0x14, %sp + std %l6, [ %sp + -20 ] + clr [ %sp + -12 ] + st %sp, [ %sp + -8 ] + clr [ %sp + -4 ] + mov 0x3b, %g1 + ta 8 + xor %o7, %o7, %o0 + mov 1, %g1 + ta 8 +``` + +``` +-bash-4.3$ gcc test.s -o test +-bash-4.3$ ./test +$ echo HELLO +HELLO +$ exit +``` + +As you can see the program works when ran directly from the shell, but when single-stepping in gdb, a SIGILL (illegal instruction) trap occurs +``` +-bash-4.3$ gdb test +GNU gdb (GDB) 7.4.1 +[...] +(gdb) disas main +Dump of assembler code for function main: + 0x0001061c <+0>: sethi %hi(0x2f626800), %l6 + 0x00010620 <+4>: or %l6, 0x16e, %l6 ! 0x2f62696e + 0x00010624 <+8>: sethi %hi(0x2f6b7000), %l7 + 0x00010628 <+12>: or %l7, 0x368, %l7 ! 0x2f6b7368 + 0x0001062c <+16>: and %sp, %sp, %o0 + 0x00010630 <+20>: add %sp, 0xc, %o1 + 0x00010634 <+24>: xor %o2, %o2, %o2 + 0x00010638 <+28>: add %sp, 0x14, %sp + 0x0001063c <+32>: std %l6, [ %sp + -20 ] + 0x00010640 <+36>: clr [ %sp + -12 ] + 0x00010644 <+40>: st %sp, [ %sp + -8 ] + 0x00010648 <+44>: clr [ %sp + -4 ] + 0x0001064c <+48>: mov 0x3b, %g1 + 0x00010650 <+52>: ta 8 + 0x00010654 <+56>: xor %o7, %o7, %o0 + 0x00010658 <+60>: mov 1, %g1 + 0x0001065c <+64>: ta 8 +End of assembler dump. +(gdb) b main +Breakpoint 1 at 0x1061c +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) si +0x00010620 in main () +(gdb) +0x00010624 in main () +[...] +Program received signal SIGILL, Illegal instruction. +0x0001063c in main () +``` + +However, if I continue execution _over_ the `std` instruction, the SIGILL does not occur. it will get to the usual SIGTRAP after execve, +but then complains about memory accesses that I've never seen before. +``` +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) c +Continuing. + +Program received signal SIGTRAP, Trace/breakpoint trap. +0xef783af4 in _rt_boot () from /usr/lib/ld.so.1 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +$ +``` + +It does eventually get a shell though. + +On mdb, instead of single-stepping into a SIGILL, everything goes unresponsive after stepping the `std` instruction. Then I have to kill mdb. diff --git a/results/classifier/deepseek-2/output/hypervisor/2396 b/results/classifier/deepseek-2/output/hypervisor/2396 new file mode 100644 index 000000000..6acdf660c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2396 @@ -0,0 +1,2 @@ + +Exception in interrupt handling after upgrading from 8.0 to 9.0 diff --git a/results/classifier/deepseek-2/output/hypervisor/2400 b/results/classifier/deepseek-2/output/hypervisor/2400 new file mode 100644 index 000000000..997f3dd56 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2400 @@ -0,0 +1,44 @@ + +Qemu fails to boot snapshot image if its header is qcow2 but its payload and backing image extension are luks +Description of problem: +Qemu fails to recognize snapshot image E:\\test_snapshot.qcow2 saying Volume is not in LUKS format + +You need three commands to reproduce: + +`qemu-img create -f luks --object secret,id=sec0,data=123 -o key-secret=sec0 E:\test.luks 1G` + +`qemu-img create --object secret,id=sec0,data=123 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 -b E:\test.luks -F luks E:\test_snapshot.qcow2` + +`qemu-system-x86_64 -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0 -object secret,id=sec0,data=123` + +This error is printed: + +`qemu-system-x86_64: -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0: Volume is not in LUKS format` + +But fourth command shows that payload of `E:\test_snapshot.qcow2` has LUKS format: + +`qemu-img info E:\test_snapshot.qcow2` + +\[output\] + +```bash +virtual size: 1 GiB (1073741824 bytes) +disk size: 2.25 MiB +encrypted: yes +cluster_size: 65536 +backing file: E:\test.luks +backing file format: luks +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + encrypt: + ivgen alg: plain64 + detached header: false + hash alg: sha256 + cipher alg: aes-256 + uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx + format: luks + cipher mode: xts ... +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/2402 b/results/classifier/deepseek-2/output/hypervisor/2402 new file mode 100644 index 000000000..03851b2ee --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2403 b/results/classifier/deepseek-2/output/hypervisor/2403 new file mode 100644 index 000000000..65d27ef94 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2403 @@ -0,0 +1,15 @@ + +WHPX accelerator fails to boot guest Windows 7 +Description of problem: +I get Qemu freezed on Starting Windows screen when trying to boot Windows 7 Professional +Steps to reproduce: +1. Run qemu with the above command line and until Starting Windows screen appears. +2. See qemu freezed. +Additional information: +tcg accelerator works ok, though (Windows 7 successfully boots as expected on native hardware): + +- `qemu-system-x86_64.exe -accel tcg -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -m 4G -machine q35 -device qxl-vga,vgamem_mb=64 -hda Windows7_Disk.qcow2 -boot d -cdrom Windows7.iso` + + This bug seems to have the same roots: https://gitlab.com/qemu-project/qemu/-/issues/1859 + + {width=579 height=477} diff --git a/results/classifier/deepseek-2/output/hypervisor/2421 b/results/classifier/deepseek-2/output/hypervisor/2421 new file mode 100644 index 000000000..37f57285e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2421 @@ -0,0 +1,19 @@ + +Cannot boot ArcaOS 5.1.0 (a distro of OS/2 Warp 4.52) in UEFI mode +Description of problem: +ArcaOS has added the UEFI support since 5.1.0, it has been tested on my physical machine(Ryzen 3300X + RTX2060 Super), and VirtualBox with an `Other x64` machine(the new OS/2 bootloader used in UEFI mode is x64 only). + +Fixes applied to #2198 are perfectly worked in legacy BIOS mode, but if I tried to boot it in UEFI mode, it will stuck on logo screen, and if I enable verbose mode in boot menu, nothing will be shown on the screen and serial ports. + +It happens in both `i440fx` machine type and `q35` machine type. +Steps to reproduce: +1. Install latest qemu HEAD version via `brew install qemu --HEAD` +2. Create new virtual disk via `qemu-img create -f qcow2 hdd.img 20G` +3. Copy EFI bios file and var file + ``` + cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-x86_64-code.fd bios.fd + cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-i386-vars.fd vars.fd + ``` +4. Launch it +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2426 b/results/classifier/deepseek-2/output/hypervisor/2426 new file mode 100644 index 000000000..dc2a4b547 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2426 @@ -0,0 +1,2 @@ + +How to determine which cpu microarchitecture is suitable for use on Windows 11? diff --git a/results/classifier/deepseek-2/output/hypervisor/2429 b/results/classifier/deepseek-2/output/hypervisor/2429 new file mode 100644 index 000000000..e4c8e658e --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/243 b/results/classifier/deepseek-2/output/hypervisor/243 new file mode 100644 index 000000000..245df003d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/243 @@ -0,0 +1,2 @@ + +Qemu refuses to multiboot Elf64 kernels diff --git a/results/classifier/deepseek-2/output/hypervisor/2436 b/results/classifier/deepseek-2/output/hypervisor/2436 new file mode 100644 index 000000000..89656c5f8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2436 @@ -0,0 +1,2 @@ + +virtio kvm iofd sigfault bypass diff --git a/results/classifier/deepseek-2/output/hypervisor/244 b/results/classifier/deepseek-2/output/hypervisor/244 new file mode 100644 index 000000000..364257cc8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/244 @@ -0,0 +1,2 @@ + +MIPS MT dvpe does not regard VPEConf0.MVP diff --git a/results/classifier/deepseek-2/output/hypervisor/2452 b/results/classifier/deepseek-2/output/hypervisor/2452 new file mode 100644 index 000000000..b73fb45a3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2452 @@ -0,0 +1,2 @@ + +memory allocation for AMDVIIOTLBEntry in amdvi_update_iotlb() diff --git a/results/classifier/deepseek-2/output/hypervisor/2461 b/results/classifier/deepseek-2/output/hypervisor/2461 new file mode 100644 index 000000000..2fffe521c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2461 @@ -0,0 +1,57 @@ + +Qemu with -accel whpx doesn't set WRMSR permissions, which blocks nested virtualization +Description of problem: +This bug blocks https://gitlab.com/qemu-project/qemu/-/issues/628 + +Qemu doesn't set the host's Hyper-V permissions for WRMSR command to allow using SVM or VMX. Unset permissions lead to `unchecked MSR access error: WRMSR to 0xc0000080` inside Linux VM when trying to launch nested VM on real AMD cpu. Intel users do not see guest VMX feature at all. Please see **Additional info** section to understand how Hyper-V permissions for nested virtualization work in Windows. +Steps to reproduce: +1. Turn on VT-x (for Intel) or AMD-V virtualization in your real hardware BIOS/EFI. This was tested only on AMD cpu and Qemu 9, Intel \*may\* behave differently. + 2. Install any distro in qemu disk c:\\linux_disk.qcow2 with MSR enabled in kernel, for example, Ubuntu 22.04 LTS. + 3. Run qemu using `qemu-system-x86_64.exe -m 2048 -machine q35 -accel whpx -cpu Opteron_G5,check,+svm -hda c:\linux_disk.qcow2` + + To check if your distro has MSR mod enabled, run `grep -i msr /boot/config-$(uname -r)` and it should return `CONFIG_X86_MSR=m` or `CONFIG_X86_MSR=y`. If not, recompile and reinstall your kernel. + 4. Run `sudo modprobe msr` and then `sudo rdmsr 0xc0000080 #EFER`. You should see `d01` on modern AMD models. \[Untested\] For intel, run `sudo modprobe msr`, then `sudo rdmsr 0x3A`. You should see `5` or `0x5` or `0x100005`. d01 for AMD and 5 for Intel in output are necessary to enable nested VM. If RDMSR returns non-zero value, it means that qemu developers implemented this part of functionality and your Hyper-V on Windows is not broken. + 5. Run `cat /proc/cpuinfo | grep -c svm` on AMD cpu, which should output a positive digit. + 6. Run `sudo dmesg | grep kvm` and note: + + `[1.924036] kvm_amd: Nested Virtualization enabled` + + `[1.924038] kvm_amd: Nested Paging disabled`\ + `[1.924040] kvm_amd: PMU virtualization is disabled` + 7. This, in theory, is sufficient for KVM-acclelerated qemu to start a nested VM. + 8. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error + 9. Run `sudo qemu-system-x86_64 -accel kvm`. A black window with "Guest has not initialized the display (yet)." appears. +10. Run `sudo dmesg` and note qemu crash starting with `unchecked MSR access error: WRMSR` + + \* Steps 1-4 are only required for diagnostics, and KVM works (in native Windows Hyper-V manager) without the necessarity to enter these commands in usual usage scenarios. If you run <span dir="">`cat /proc/cpuinfo | grep -c vmx` on Intel cpu</span> on Step 5, you may get zero. See Step 5 of Additional Info to understand why. + + \ + Microsoft released useful info about how to look into Hyper-V MSR access problems:\ + WRMSR research in Hyper-V - https://msrc.microsoft.com/blog/2018/12/first-steps-in-hyper-v-research/ +Additional information: +By default, Hyper-V manager in Windows does not allow nested virtualization.\ +To see what happens, do the following: + + 1. Open Hyper-V manager built in the host Windows and create default Ubuntu 22.04 LTS suggested. Upon installation, shut down the VM. Note the name of the VM ("Ubuntu 22.04 LTS" by default). + 2. Open Powershell console in the host and run `Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $false` + 3. Launch guest Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. No output. + 4. Run `sudo rdmsr 0xc0000080 #EFER` that outputs d01, which means that Hyper-V manager allows this **ring 0 level** operation. + 5. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `0`. + 6. Shut the VM down. + 7. Now, Open Powershell console and `run Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $true` + 8. Launch Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. Output: + + `[2.369144] kvm: Nested Virtualization enabled` + + `[2.369146] SVM: kvm: Nested Paging enabled` + + `[2.369148] SVM: kvm: Hyper-V enlightened NPT TLB flush enabled` + + `[2.369149] SVM: kvm: Hyper-V Direct TLB flush enabled` + + `[2.369153] SVM: Virtual VMLOAD VMSAVE supported` + 9. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `1` or other positive digit, depending on the number of cpus you've assigned to the VM. +10. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error +11. Run `sudo qemu-system-x86_64 -accel kvm` and it successfully boots into qemu BIOS. +12. Running `sudo qemu-system-x86_64 -accel kvm` calls WRMSR in background, so if you see\ + booted qemu BIOS in KVM, wrmsr was successfully called. diff --git a/results/classifier/deepseek-2/output/hypervisor/2473 b/results/classifier/deepseek-2/output/hypervisor/2473 new file mode 100644 index 000000000..53153a461 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2473 @@ -0,0 +1,4 @@ + +qemu-system-aarch64: Stop execution on unhandled exceptions +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2480 b/results/classifier/deepseek-2/output/hypervisor/2480 new file mode 100644 index 000000000..d4049ddfe --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/249 b/results/classifier/deepseek-2/output/hypervisor/249 new file mode 100644 index 000000000..1bb7154f4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/249 @@ -0,0 +1,2 @@ + +guest OS catches a page fault bug when running dotnet diff --git a/results/classifier/deepseek-2/output/hypervisor/2514 b/results/classifier/deepseek-2/output/hypervisor/2514 new file mode 100644 index 000000000..915fc57e7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2514 @@ -0,0 +1,2 @@ + +network unreachable to esxi 8 guest diff --git a/results/classifier/deepseek-2/output/hypervisor/252 b/results/classifier/deepseek-2/output/hypervisor/252 new file mode 100644 index 000000000..bafdeb424 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/252 @@ -0,0 +1,2 @@ + +KVM Old ATI(pre) AMD card passthrough is not working diff --git a/results/classifier/deepseek-2/output/hypervisor/2527 b/results/classifier/deepseek-2/output/hypervisor/2527 new file mode 100644 index 000000000..492318e09 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2527 @@ -0,0 +1,2 @@ + +bFLT parser doesn't select MMU-less CPU diff --git a/results/classifier/deepseek-2/output/hypervisor/2541 b/results/classifier/deepseek-2/output/hypervisor/2541 new file mode 100644 index 000000000..8c5c953ff --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2541 @@ -0,0 +1,2 @@ + +virtio-9p qos-test failure: v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73) FAIL diff --git a/results/classifier/deepseek-2/output/hypervisor/2543 b/results/classifier/deepseek-2/output/hypervisor/2543 new file mode 100644 index 000000000..8057b9cc4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2543 @@ -0,0 +1,12 @@ + +QEMU UEFI for riscv64 failed to load my DIY bootloader due to unknown reason +Steps to reproduce: +1. [ProblematicBootLoader.zip](/uploads/21fcff0052dc2dd95bf4bba3f6ec8fb8/ProblematicBootLoader.zip) unpack this zipped file,create a fat.img which contains FAT32 file system,and then move the unpacked file in the zip to /EFI/BOOT/bootriscv64.efi.After that using xorriso to pack it. +2. Load the cdrom in libvirt(virt-manager) using SCSI/USB +3. Then wait for seconds and error will show(I don't why STORE_ACCESS_PAGE_FAULT occurs) +Additional information: +My full source code is in https://github.com/TYDQSoft/UEFIPascalOS. + +You can get the instruction in the github to compile this problematic bootloader for testing. + +x64,AArch64 was tested successfully,but riscv64 is always problematic in evert test times. diff --git a/results/classifier/deepseek-2/output/hypervisor/2545 b/results/classifier/deepseek-2/output/hypervisor/2545 new file mode 100644 index 000000000..93a3d805b --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2556 b/results/classifier/deepseek-2/output/hypervisor/2556 new file mode 100644 index 000000000..0d4553156 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2568 b/results/classifier/deepseek-2/output/hypervisor/2568 new file mode 100644 index 000000000..052ccdc8d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2568 @@ -0,0 +1,2 @@ + +[AARCH64] HPFAR_EL2.NS not set for non secure read in S-EL1 diff --git a/results/classifier/deepseek-2/output/hypervisor/2573 b/results/classifier/deepseek-2/output/hypervisor/2573 new file mode 100644 index 000000000..2f0c878b4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2573 @@ -0,0 +1,10 @@ + +RISC-V: Executing floating point instruction in VS mode under KVM acceleration leads to crash +Description of problem: +Executing `fcvt.d.w fa5,a5` in VS mode leads to crash. +Steps to reproduce: +1. Download the Ubuntu 24.10 image https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/oracular-preinstalled-server-riscv64.img.xz +2. On your amd64 system launch a VM using -accel tcg +3. Inside the VM launch a new VM using -accel kvm with the payload mentioned above +Additional information: +For more details see https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2077731 diff --git a/results/classifier/deepseek-2/output/hypervisor/2579 b/results/classifier/deepseek-2/output/hypervisor/2579 new file mode 100644 index 000000000..b69fcff53 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2582 b/results/classifier/deepseek-2/output/hypervisor/2582 new file mode 100644 index 000000000..c09774ad0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2582 @@ -0,0 +1,24 @@ + +CR4.VMX leaks from L1 into L2 on Intel VMX +Description of problem: +In a nested virtualization setting, `savevm` can cause CR4 bits from leaking from L1 into L2. This causes general-protection faults in certain guests. + +The L2 guest executes this code: + +``` +mov rax, cr4 ; Get CR4 +mov rcx, rax ; Remember the old value +btc rax, 7 ; Toggle CR4.PGE +mov cr4, rax ; #GP! <- Shouldn't happen! +mov cr4, rcx ; Restore old value +``` + +If the guest code is interrupted at the right time (e.g. via `savevm`), Qemu marks CR4 dirty while the guest executes L2 code. Due to really complicated KVM semantics, this will result in L1 CR4 bits (VMXE) leaking into the L2 guest and the L2 will die with a GP: + +Instead of the expected CR4 value, the L2 guest reads a value with VMXE set. When it tries to write this back into CR4, this triggers the general protection fault. +Steps to reproduce: +This is only an issue on **Intel** systems. + +# +Additional information: +See also this discussion where we discussed a (flawed) approach to fixing this in KVM: https://lore.kernel.org/lkml/Zh6WlOB8CS-By3DQ@google.com/t/ diff --git a/results/classifier/deepseek-2/output/hypervisor/2587 b/results/classifier/deepseek-2/output/hypervisor/2587 new file mode 100644 index 000000000..292e0835f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2587 @@ -0,0 +1,2 @@ + +Avoid using error_setg(&error_fatal, ...) in the QEMU sources diff --git a/results/classifier/deepseek-2/output/hypervisor/2588 b/results/classifier/deepseek-2/output/hypervisor/2588 new file mode 100644 index 000000000..90fe41f02 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2588 @@ -0,0 +1,44 @@ + +qemu-system-arm regression: NonSecure World can change Secure World MMU mapping. +Description of problem: +A NonSecure execution context is able to override MMU L1 translation table +flags set by Secure context on Secure World memory. + +This is not consistent with the same code running on real hardware and it's a +regression over past qemu releases as 9.0.0 behaves correctly. +Steps to reproduce: +This has been tested with +[GoTEE-example](https://github.com/usbarmory/GoTEE-example) as follows: + +``` +# building tamago +wget https://github.com/usbarmory/tamago-go/archive/refs/tags/latest.zip +unzip latest.zip +cd tamago-go-latest/src && ./all.bash +cd ../bin && export TAMAGO=`pwd`/go + +# building and running GoTEE-example +wget https://github.com/usbarmory/GoTEE-example/archive/refs/heads/master.zip +unzip master.zip +cd GoTEE-example +export TARGET=usbarmory && make clean && make nonsecure_os_go && make trusted_applet_go && make trusted_os && make qemu +``` + +# +Additional information: +The issue relates to the fact that the NonSecure World, at startup, configures +the MMU with the NX bit for the entire address space not belonging to its +firmware .text area. + +On real hardware this MMU configuration by NonSecure world does not affect the +Secure World translation tables. + +On qemu 9.1.0, however it does and this is inconsistent with real hardware +behavior. On qemu 9.0.0 the behaviour is correct so the issue has been +introduced between these two releases. + +The switch between Secure and NonSecure is done +[here](https://github.com/usbarmory/GoTEE/blob/7e62563c0628fed3ee0aebb4702e22be9bb636e3/monitor/exec_arm.s#L73). + +The MMU first level address table which sets the NX bit is done +[here](https://github.com/usbarmory/tamago/blob/273d67cd811dfcb1782c0fe596ac14d43d0ce117/arm/mmu.go#L85). diff --git a/results/classifier/deepseek-2/output/hypervisor/2620 b/results/classifier/deepseek-2/output/hypervisor/2620 new file mode 100644 index 000000000..52ea87135 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2620 @@ -0,0 +1,10 @@ + +Freezes when installing NeXTSTEP 3.3 or OPENSTEP 4.2 RISC version in qemu-system-sparc +Description of problem: + +Steps to reproduce: +1.Boot from NeXTstep 3.3 or OPENSTEP 4.2 RISC ISO. Works on real Sparcstation 5, 10, or 20 +2.Start OS install +3. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2626 b/results/classifier/deepseek-2/output/hypervisor/2626 new file mode 100644 index 000000000..3006888fe --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2626 @@ -0,0 +1,9 @@ + +QEMU crashes after host time moves backwards +Description of problem: +QEMU process crashes after time synchronized and moved backwards on the host. +Steps to reproduce: +As detailed in the [thread](https://bugzilla.redhat.com/show_bug.cgi?id=2228406) + +1. create a virtual machine and change tick period in the guest +2. executing `while [ 1 ];do hwclock --systohc; hwclock --hctosys;done` on the host diff --git a/results/classifier/deepseek-2/output/hypervisor/2627 b/results/classifier/deepseek-2/output/hypervisor/2627 new file mode 100644 index 000000000..3e18305e4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2627 @@ -0,0 +1,2 @@ + +Possible incorrect exception order in RISC-V diff --git a/results/classifier/deepseek-2/output/hypervisor/2642 b/results/classifier/deepseek-2/output/hypervisor/2642 new file mode 100644 index 000000000..fb7c17a47 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2642 @@ -0,0 +1,6 @@ + +guest-set-time not supported +Description of problem: +guest-set-time is not supported un Ubuntu 24.04 guests. It still works on a Ubuntu 22.04 guest and on W10 and W11 guests + +feedback from the Ubuntu 24.04 guest: error: internal error: unable to execute QEMU agent command 'guest-set-time': this feature or command is not currently supported diff --git a/results/classifier/deepseek-2/output/hypervisor/2646 b/results/classifier/deepseek-2/output/hypervisor/2646 new file mode 100644 index 000000000..7e2dedf2c --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2653 b/results/classifier/deepseek-2/output/hypervisor/2653 new file mode 100644 index 000000000..4d12308c3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2653 @@ -0,0 +1,2 @@ + +Intel iGPU sriov diff --git a/results/classifier/deepseek-2/output/hypervisor/2654 b/results/classifier/deepseek-2/output/hypervisor/2654 new file mode 100644 index 000000000..065514533 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2654 @@ -0,0 +1,15 @@ + +qemu-system-i386 no longer boots NetBSD +Description of problem: +Since qemu commit b56617bbcb473c25815d1bf475e326f84563b1de, qemu-system-i386 can no longer boot NetBSD. +Steps to reproduce: +``` +wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/images/NetBSD-10.0-i386.iso +qemu-system-i386 -cdrom NetBSD-10.0-i386.iso +``` + +Expected behavior: Boots into the NetBSD installer + +Observed incorrect behavior: Boot hangs with a black screen +Additional information: +This regression is a critical issue to the NetBSD project as its automated testing infrastructure is heavily dependent on qemu-system-i386. diff --git a/results/classifier/deepseek-2/output/hypervisor/2658 b/results/classifier/deepseek-2/output/hypervisor/2658 new file mode 100644 index 000000000..1261eb6e8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2658 @@ -0,0 +1,2 @@ + +How to simulate the L2MERRSR_EL1 register in KVM mode？ diff --git a/results/classifier/deepseek-2/output/hypervisor/2673 b/results/classifier/deepseek-2/output/hypervisor/2673 new file mode 100644 index 000000000..4ac7d4227 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2673 @@ -0,0 +1,6 @@ + +qemu-system-riscv32 does not pass official riscv-tests +Description of problem: +I run riscv-tests using the above command and find qemu raises Illegalinstruction when `sret` in the machine mode.Therefore qemu cannot pass the rv32ui-v-and test. +Additional information: +The tests https://github.com/riscv-software-src/riscv-tests diff --git a/results/classifier/deepseek-2/output/hypervisor/2678 b/results/classifier/deepseek-2/output/hypervisor/2678 new file mode 100644 index 000000000..c9866dee5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2678 @@ -0,0 +1,10 @@ + +virsh blockcommit failed, however the snapshot was merged into base successfully. +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2693 b/results/classifier/deepseek-2/output/hypervisor/2693 new file mode 100644 index 000000000..4110754d1 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2699 b/results/classifier/deepseek-2/output/hypervisor/2699 new file mode 100644 index 000000000..3a05035c6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2699 @@ -0,0 +1,19 @@ + +kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9) +Description of problem: +QEMU 9.1.91 monitor - type 'help' for more information +(qemu) kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9) +test.sh: line 14: 105283 Aborted (core dumped) /usr/local/bin/qemu-system-x86_64 -M q35 -m 8G -smp 8 -cpu host -enable-kvm -device VGA,bus=pcie.0,addr=0x2 -drive file=//home/fedora-38.qcow2,media=disk,if=virtio -device virtio-net-pci,mac=00:11:22:33:44:00,netdev=id8cxFGH,id=idaFLYjy,bus=pcie.0,addr=0x7 -netdev tap,id=id8cxFGH,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -vnc :0 -monitor stdio -qmp tcp:0:5555,server,nowait +Steps to reproduce: +1. Boot a guest +2. set_link false nic and set_link true nic + +{"execute": "qmp_capabilities"} +{"return": {}} +{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": false}} +{"return": {}} +{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": true}} + +3. Guest hit qemu core dump +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/270 b/results/classifier/deepseek-2/output/hypervisor/270 new file mode 100644 index 000000000..c33db0238 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/270 @@ -0,0 +1,2 @@ + +virtio only support packed ring size power of 2 diff --git a/results/classifier/deepseek-2/output/hypervisor/2708 b/results/classifier/deepseek-2/output/hypervisor/2708 new file mode 100644 index 000000000..896526cf7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2708 @@ -0,0 +1,2 @@ + +aarch64 register MDCCINT_EL1 exhibits bizzare behavior diff --git a/results/classifier/deepseek-2/output/hypervisor/2712 b/results/classifier/deepseek-2/output/hypervisor/2712 new file mode 100644 index 000000000..55742c5fe --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2712 @@ -0,0 +1,12 @@ + +Windows VM doesn't boot on QEMU KVM when hypervisor is disabled in Linux 6.12 +Description of problem: +Windows VM doesn't boot on QEMU KVM when hypervisor is disabled in Linux 6.12. QEMU uses 100% CPU core usage and nothing happens. + +It boots properly in Linux 6.11.10. I don't know if it's a kernel bug or QEMU needs some changes to work with the new kernel correctly. +Steps to reproduce: +1. Boot Windows 10 or 11 (can be installation ISO form official website) with KVM, but set "hypervisor=off" CPU parameter. +2. Wait. +3. Nothing happens - doesn't boot. +Additional information: +Nothing is displayed in console. diff --git a/results/classifier/deepseek-2/output/hypervisor/2713 b/results/classifier/deepseek-2/output/hypervisor/2713 new file mode 100644 index 000000000..7f2456cd9 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/274 b/results/classifier/deepseek-2/output/hypervisor/274 new file mode 100644 index 000000000..71ecb8b8c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/274 @@ -0,0 +1,2 @@ + +FIXME xhci_alloc_device_streams:972 guest streams config not identical for all eps diff --git a/results/classifier/deepseek-2/output/hypervisor/2754 b/results/classifier/deepseek-2/output/hypervisor/2754 new file mode 100644 index 000000000..bbbc04fba --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2754 @@ -0,0 +1,27 @@ + +Virt-manager using QEMU exit in flash and return an I/O Error when attempting to create an loongarch64 QEMU virtual machine +Description of problem: +Cannot complete the installation:'Enter the end of the file when reading data:I/O Error' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, 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 726, in start_install + domain = self._create_guest( + guest, meter, initial_xml, final_xml, + doboot, transient) + File "/usr/share/virt-manager/virtinst/install/installer.py", line 667, in _create_guest + domain = self.conn.createXML(initial_xml or final_xml, 0) + File "/usr/lib64/python3.13/site-packages/libvirt.py", line 4545, in createXML + raise libvirtError('virDomainCreateXML() failed') +libvirt.libvirtError: 'Enter the end of the file when reading data:I/O Error' +Steps to reproduce: +1.Click to create loongarch64 virtual machine using virt-manager +2.Configure all arguments of virtual machine +3.Then click start installation,then the error occurs. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2755 b/results/classifier/deepseek-2/output/hypervisor/2755 new file mode 100644 index 000000000..469eb3fc2 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2763 b/results/classifier/deepseek-2/output/hypervisor/2763 new file mode 100644 index 000000000..251dcc107 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2763 @@ -0,0 +1,25 @@ + +RISC-V APLIC emulation: interrupt pending state of direct-delivery level-triggered interrupts is wrong after masking +Description of problem: +According to the APLIC specification, the interrupt pending state of a level-triggered interrupt in direct delivery mode should always match the (rectified) input signal: + +> When an interrupt domain is in direct delivery mode, the pending bit for a level-sensitive source is always just a copy of the rectified input value. + +(From Section 4.7 "Precise effects on interrupt-pending bits" of the specification. See also the more detailed paragraph starting with "If the + source mode is Level1 or Level0 and the interrupt domain is configured in direct delivery mode [...]".) + +However, **this is not true in Qemu's emulation**. In particular, in some situations, **a level-triggered interrupt in direct delivery mode can be raised even though the rectified input signal is off**. +Steps to reproduce: +1. Set `-machine virt,acpi=off,aia=aplic` to use AIA without IMSIC. +2. Program APLIC to direct delivery. Program some level triggered interrupt (e.g., an interrupt of a PCIe ECAM controller). +4. Wait until the IRQ is raised by a device (i.e., `claimi` returns the IRQ). +5. Mask the interrupt by writing to `clrie`. +6. Clear the interrupt at the device level. +7. The state of Qemu's APLIC registers is now: + ``` + Rectified input = 0 (correct) + Pending = 1 (incorrect) + topi = 0 (correct) + ``` + +Furthermore, if `setie` is written to unmask the IRQ in this situation, the IRQ is raised (in `topi` / `claimi`) despite the signal being off. diff --git a/results/classifier/deepseek-2/output/hypervisor/2779 b/results/classifier/deepseek-2/output/hypervisor/2779 new file mode 100644 index 000000000..ab6cac739 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2779 @@ -0,0 +1,42 @@ + +Segmentation fault when introspecting machine properties +Description of problem: +QEMU currrently crashes when trying to list the properties of the q35 machine type while QEMU has been started with the i440fx machine type. Introspecting QOM objects for their properties should always be possible, but apparently there is currently something causing a crash in this case. +Steps to reproduce: +1. Start QEMU with: qemu-system-x86_64 -M pc -qmp stdio +2. Enter these commands in the QMP monitor: + +``` + { "execute": "qmp_capabilities" } + { "execute": "qom-list-properties","arguments": { "typename": "pc-q35-10.0-machine"}} +``` +Additional information: +Backtrace looks like this: +``` +mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738 +738 s->cmos_data[addr] = val; +--Type <RET> for more, q to quit, c to continue without paging--#0 mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738 +#1 0x0000555555bf15d2 in pc_machine_done (notifier=0x555557f40750, data=<optimized out>) at ../../devel/qemu/hw/i386/pc.c:632 +#2 0x0000555555d4f7a2 in object_init_with_type (obj=obj@entry=0x555557f40320, ti=ti@entry=0x5555579c3c60) + at ../../devel/qemu/qom/object.c:424 +#3 0x0000555555d49c7e in object_initialize_with_type (obj=0x555557f40320, size=<optimized out>, type=type@entry=0x5555579c3c60) + at ../../devel/qemu/qom/object.c:570 +#4 0x0000555555d4a660 in object_new_with_type (type=0x5555579c3c60) at ../../devel/qemu/qom/object.c:774 +#5 object_new (typename=typename@entry=0x555558672b30 "pc-q35-10.0-machine") at ../../devel/qemu/qom/object.c:789 +#6 0x0000555555e825c5 in qmp_qom_list_properties (typename=0x555558672b30 "pc-q35-10.0-machine", errp=errp@entry=0x7fffffffd988) + at ../../devel/qemu/qom/qom-qmp-cmds.c:205 +#7 0x0000555555ef0525 in qmp_marshal_qom_list_properties (args=<optimized out>, ret=0x7fffeda9af00, errp=0x7fffeda9af08) + at qapi/qapi-commands-qom.c:288 +#8 0x0000555555f1edc1 in do_qmp_dispatch_bh (opaque=0x7fffeda9aed0) at ../../devel/qemu/qapi/qmp-dispatch.c:128 +#9 0x0000555555f40e28 in aio_bh_poll (ctx=ctx@entry=0x5555579f2930) at ../../devel/qemu/util/async.c:219 +#10 0x0000555555f2886f in aio_dispatch (ctx=0x5555579f2930) at ../../devel/qemu/util/aio-posix.c:424 +#11 0x0000555555f41cbb in aio_ctx_dispatch (source=0x0, callback=0x5f, user_data=<optimized out>) at ../../devel/qemu/util/async.c:361 +#12 0x00007ffff6d98e8c in g_main_context_dispatch_unlocked.lto_priv () at /lib64/libglib-2.0.so.0 +#13 0x00007ffff6d99155 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#14 0x0000555555f42540 in glib_pollfds_poll () at ../../devel/qemu/util/main-loop.c:287 +#15 os_host_main_loop_wait (timeout=<optimized out>) at ../../devel/qemu/util/main-loop.c:310 +#16 main_loop_wait (nonblocking=nonblocking@entry=0) at ../../devel/qemu/util/main-loop.c:589 +#17 0x0000555555ae1207 in qemu_main_loop () at ../../devel/qemu/system/runstate.c:835 +#18 0x0000555555e85d57 in qemu_default_main (opaque=<optimized out>) at ../../devel/qemu/system/main.c:48 +#19 0x0000555555e85d2f in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:76 +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/2782 b/results/classifier/deepseek-2/output/hypervisor/2782 new file mode 100644 index 000000000..1d7478e31 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2782 @@ -0,0 +1,11 @@ + +WHPX won't enable x86_64v3 level instructions +Description of problem: +x86_64v3 support is not available inside guest +Steps to reproduce: +1. Boot the image +2. Open terminal +3. Run `/lib64/ld-linux-x86-64.so.2 --help` and check which levels are available in the output +4. Or run `/lib64/ld-linux-x86-64.so.2 --list-diagnostics | grep isa` and check `isa_1` value (expected 7 for v3 (3 bits being set)) +Additional information: +Due to this some Linux distribution, like Centos Stream 10, will not be able to boot with WHPX acceleration enabled. diff --git a/results/classifier/deepseek-2/output/hypervisor/279 b/results/classifier/deepseek-2/output/hypervisor/279 new file mode 100644 index 000000000..4ce85c33d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/279 @@ -0,0 +1,2 @@ + +x86-64 MTTCG Does not update page table entries atomically diff --git a/results/classifier/deepseek-2/output/hypervisor/2791 b/results/classifier/deepseek-2/output/hypervisor/2791 new file mode 100644 index 000000000..b01153c97 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2791 @@ -0,0 +1,64 @@ + +"Missing character write event in the replay log" when trying rr=replay with snapshot +Description of problem: +Probably best to just illustrate with commands. Happy path: + +```sh +rm replay.bin snapshots.qcow2; qemu-img create -f qcow2 snapshots.qcow2 256M + +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=record,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" + +# It runs, guest kernel crashes when realising it has no rootfs, all good +du -sh snapshots.qcow2 # 976K + +# Repeat same command just switched to rr=replay +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=replay,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" +# Much slower, but same result. All good +``` + +But, I want to take a snapshot later in boot. + +```sh +rm replay.bin snapshots.qcow2; qemu-img create -f qcow2 snapshots.qcow2 256M + +# This time, running with debug. Also have to switch to -monitor stdio because of +# https://gitlab.com/qemu-project/qemu/-/issues/2790 +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -monitor stdio \ + -icount shift=auto,rr=record,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" \ + -s -S + +# In another terminal, attach a debugger, set a breakpoint, continue to the breakpoint +gdb -ex "target remote localhost:1234" .kunit/vmlinux +(gdb) hb start_kernel +(gdb) continue + +# When the breakpoint is hit, back in the first terminal: +(qemu) savevm test +(qemu) quit + +du -sh snapshots.qcow2 # 21M + +# Now try to replay again +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=replay,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" +``` + +Result: + +``` +qemu-system-x86_64: Missing character write event in the replay log (insn total 1598039/586 left, event 886 is EVENT_INSTRUCTION) +fish: Job 1, '~/src/qemu/build/qemu-system-x8…' terminated by signal -icount shift=auto,rr=repla… ( -drive file=snapshots.qcow2…) +fish: Job -kernel ./.kunit/arch/x86/b…, 'SIGABRT' terminated by signal Abort () +``` + +Exit code is 134. diff --git a/results/classifier/deepseek-2/output/hypervisor/2794 b/results/classifier/deepseek-2/output/hypervisor/2794 new file mode 100644 index 000000000..0d3b104a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2794 @@ -0,0 +1,50 @@ + +qemu-system-m68k virt machine doesn't boot Linux kernels using 68020, 68030 and 68060 CPUs +Description of problem: +QEMU doesn't seem to be able to start Linux kernels using a CPU other than a 68040 (which does work fine) + +To rule out host issues, the issue is reproductible on Debian Unstable amd64 (with version QEMU emulator version 9.2.0)(Debian 1:9.2.0+ds-5)) + +To rule out cross-compilation issues, the kernel has been rebuild inside a virt machine (using a 68040 CPU), running Debian Unstable + +Each CPU model below gets stuck early before kernel boot during the ABCGHIJK thing. The Kernel doesn't seem to boot and QEMU process eat 100% of a CPU physical core + +**68020** +``` +qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux +ABCGH +``` + +**68030** +``` +qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux +ABC +``` + +**68060** +``` +qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux +ABC +``` +Steps to reproduce: +1. build a kernel with 68020/030/060 support (using virt_defconfig as base) +2. start QEMU with the command line above +Additional information: +68020 is understandable as it may need some sort of 68851 emulation. + +Relevant Kernel config Processor configuration: +``` +# +# Processor Type +# +CONFIG_M68KCLASSIC=y +# CONFIG_COLDFIRE is not set +CONFIG_M68020=y +CONFIG_M68030=y +CONFIG_M68040=y +CONFIG_M68060=y +``` + +This may be related to the following issues (but I don't have the skillset to confirm that) +- https://gitlab.com/qemu-project/qemu/-/issues/2091 +- https://gitlab.com/qemu-project/qemu/-/issues/2500 diff --git a/results/classifier/deepseek-2/output/hypervisor/2800 b/results/classifier/deepseek-2/output/hypervisor/2800 new file mode 100644 index 000000000..b8287fb5c --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2818 b/results/classifier/deepseek-2/output/hypervisor/2818 new file mode 100644 index 000000000..5a40b72f6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2828 b/results/classifier/deepseek-2/output/hypervisor/2828 new file mode 100644 index 000000000..c221e8a06 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2828 @@ -0,0 +1,4 @@ + +Potential issues at Interrupt filtering and virtual interrupts for supervisor level (RISC-V AIA) +Description of problem: +I am working on RISC-V Advanced Interrupt Architecture (AIA) compliance tests for our RISC-V core. These tests pass on our hardware implementation but fail when running on QEMU. There are several points where the tests fail while running in QEMU: diff --git a/results/classifier/deepseek-2/output/hypervisor/2830 b/results/classifier/deepseek-2/output/hypervisor/2830 new file mode 100644 index 000000000..ff1126a46 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2830 @@ -0,0 +1,2 @@ + +gdbstub: breakpoint/watchpoint increments warp timer on single-core icount mode, breaking determinism diff --git a/results/classifier/deepseek-2/output/hypervisor/2834 b/results/classifier/deepseek-2/output/hypervisor/2834 new file mode 100644 index 000000000..bd0105fd8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2834 @@ -0,0 +1,20 @@ + +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] +Description of problem: +when run `./qemu-system-x86_64 -cpu host,intel_pt -m 8192M -smp 4 -hda ubuntu.qcow2 --enable-kvm --nographic` warning `qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]`. +Tried adding level/min-level=0x14, but still received a warning. +Steps to reproduce: +run command +``` +./qemu-system-x86_64 -cpu host,intel_pt -m 8192M -smp 4 -hda ubuntu.qcow2 --enable-kvm --nographic +``` +Additional information: +- CPU i5-13600kf +``` +~$ sudo rdmsr 0x485 -f 14:14 # MSR_IA32_VMX_MISC_INTEL_PT +1 +~$ sudo rdmsr 0x48B -f 56:56 # SECONDARY_EXEC_PT_USE_GPA +1 +~$ sudo rdmsr 0x484 -f 50:50 # VM_ENTRY_LOAD_IA32_RTIT_CTL +1 +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/2839 b/results/classifier/deepseek-2/output/hypervisor/2839 new file mode 100644 index 000000000..4cb2f4b39 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2839 @@ -0,0 +1,36 @@ + +Physical memory usage spikes after migration for a VM using memory-backend-memfd memory +Description of problem: +When starting a virtual machine using the memory-backend-memfd type memory, configuring the virtual machine memory to 256GB or any other size, the QEMU process initially allocates only a little over 4GB of physical memory. However, after migrating the virtual machine, the physical memory occupied by the QEMU process almost equals 256GB. In an overcommitted memory environment, the increase in physical memory usage by the virtual machine can lead to insufficient host memory, triggering Out-Of-Memory (OOM). +Steps to reproduce: +1. start vm +./qemu-system-x86_64 -accel kvm -cpu SandyBridge -object memory-backend-memfd,id=mem1,size=256G -machine memory-backend=mem1 -smp 4 -drive file=/nvme0n1/luzhipeng/fusionos.qcow2,if=none,id=drive0,cache=none -device virtio-blk,drive=drive0,bootindex=1 -monitor stdio -vnc :0 +2. start vm on another host +./qemu-system-x86_64 -accel kvm -cpu SandyBridge -object memory-backend-memfd,id=mem1,size=256G -machine memory-backend=mem1 -smp 4 -drive file=/nvme0n1/luzhipeng/fusionos.qcow2,if=none,id=drive0,cache=none -device virtio-blk,drive=drive0,bootindex=1 -monitor stdio -vnc :0 -incoming tcp:0.0.0.0:4444 +3. migrate vm +migrate -d tcp:xx.xx.xx.xx:4444 +4. +Check QEMU process memory usage with the top command + +``` +top - 14:01:05 up 35 days, 20:16, 2 users, load average: 0.22, 0.23, 0.18 +Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie +%Cpu(s): 0.2 us, 0.1 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +MiB Mem : 514595.3 total, 2642.6 free, 401703.3 used, 506435.3 buff/cache +MiB Swap: 0.0 total, 0.0 free, 0.0 used. 112892.0 avail Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +3865345 root 20 0 257.7g 256.1g 256.0g S 1.3 51.0 3:14.44 qemu-system-x86 +``` +Additional information: +``` +The relevant code: +void ram_handle_zero(void *host, uint64_t size) +{ + if (!buffer_is_zero(host, size)) { + memset(host, 0, size); + } +} +``` + +In the memory migration process, for the migration of zero pages, the destination side calls buffer_is_zero to check whether the corresponding page is entirely zero. If it is not zero, it actively sets it as a full page. For memory of the memfd type, the first access will allocate physical memory, resulting in physical memory allocation for all zero pages of the virtual machine. diff --git a/results/classifier/deepseek-2/output/hypervisor/2848 b/results/classifier/deepseek-2/output/hypervisor/2848 new file mode 100644 index 000000000..33a447837 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2850 b/results/classifier/deepseek-2/output/hypervisor/2850 new file mode 100644 index 000000000..cb4aa9e54 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2850 @@ -0,0 +1,4 @@ + +Available in a version for Windows on arm +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2855 b/results/classifier/deepseek-2/output/hypervisor/2855 new file mode 100644 index 000000000..1ebe5d467 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2855 @@ -0,0 +1,30 @@ + +masking mode field in mepc before mret +Description of problem: +I thought I found a bug in OpenSBI (https://github.com/riscv-software-src/opensbi/issues/391) but it actually is a QEMU bug. +It is described here: https://lists.infradead.org/pipermail/opensbi/2025-March/008166.html +Steps to reproduce: +1. use an application with vectored mode enabled (The RISC-V Instruction Set Manual: Volume II: Privileged Architecture / chapter 10.1.2) in QEMU +2. trigger an illegal instruction interrupt (handle it in machine mode - not by medeleg) +3. in a machine mode trap: Store STVEC in MEPC. +4. do a mret +5. the first bits of mepc are not masked so the address in mepc (comming from (v)stvec) will be false after mret +Additional information: +My guess is that the instructions from the following quote (masking of lower bits in mepc) from the official spec must be implemented here: +https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/op_helper.c?ref_type=heads#L387 +Maybe also somewhere else. + +> 3.1.14. Machine Exception Program Counter (mepc) +> +> mepc is an MXLEN-bit read/write register formatted as shown in Figure 21. The low bit of mepc +> (mepc[0]) is always zero. On implementations that support only IALIGN=32, the two low bits +> (mepc[1:0]) are always zero. +> +> If an implementation allows IALIGN to be either 16 or 32 (by changing CSR misa, for example), then, +> whenever IALIGN=32, bit mepc[1] is masked on reads so that it appears to be 0. This masking occurs +> also for the implicit read by the MRET instruction. Though masked, mepc[1] remains writable when +> IALIGN=32. +> +> mepc is a WARL register that must be able to hold all valid virtual addresses. It need not be capable of +> holding all possible invalid addresses. Prior to writing mepc, implementations may convert an invalid +> address into some other invalid address that mepc is capable of holding. diff --git a/results/classifier/deepseek-2/output/hypervisor/2862 b/results/classifier/deepseek-2/output/hypervisor/2862 new file mode 100644 index 000000000..d3675bdcb --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2869 b/results/classifier/deepseek-2/output/hypervisor/2869 new file mode 100644 index 000000000..688f6ed41 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2869 @@ -0,0 +1,4 @@ + +enable guest mode at amd iommu +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/2874 b/results/classifier/deepseek-2/output/hypervisor/2874 new file mode 100644 index 000000000..513be3f44 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2875 b/results/classifier/deepseek-2/output/hypervisor/2875 new file mode 100644 index 000000000..5b816bc20 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2875 @@ -0,0 +1,30 @@ + +[Virtio-GPU Venus] QEMU Virtio-GPU Venus with Lavapipe ICD shows corrupted graphical output along with error prints +Description of problem: +QEMU Virtio-GPU Venus with Lavapipe ICD shows corrupted graphical output (screenshots attached ahead) along with the following error prints, as guest_errors are enabled in QEMU command line `-d guest_errors`: +``` +VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json ./qemu-system-x86_64 -enable-kvm -M q35 -smp 4 -m 4G -cpu host -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 -d guest_errors -device virtio-vga-gl,hostmem=4G,blob=true,venus=true -vga none -display gtk,gl=on,show-cursor=on -usb -device usb-tablet -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1 -hda ubuntu-2504.qcow2 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +``` +Steps to reproduce: +1. Used steps mentioned here: https://gist.github.com/peppergrayxyz/fdc9042760273d137dddd3e97034385f, to build virglrenderer-1.1.0 with Venus support, and to build QEMU (latest: v10.0.0-rc1) with virglrenderer support. +2. Run QEMU with Lavapipe ICD using the command shared above. +3. When the QEMU guest is up, install required packages such as `sudo apt-get install -y mesa* vulkan* libvulkan* vkmark` and run vkcube / vkmark with VirtIO ICD: +``` +VK_DRIVER_FILES=/usr/share/vulkan/icd.d/virtio_icd.x86_64.json vkcube --wsi wayland +``` +Additional information: +Attaching screenshots for the error observed on guest side: +,  +Collected logs with tracing enabled (`meson setup -Dvenus=true -Dvenus-validate=true -Dvideo=true -Dtracing=stderr build`) in virglrenderer as well: [virgl-tracing-stderr.log](/uploads/202c698b7c265cde7c83b441a6a7abdb/virgl-tracing-stderr.log). Search for error in the log file. diff --git a/results/classifier/deepseek-2/output/hypervisor/2877 b/results/classifier/deepseek-2/output/hypervisor/2877 new file mode 100644 index 000000000..da5b85dd5 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2879 b/results/classifier/deepseek-2/output/hypervisor/2879 new file mode 100644 index 000000000..d535951af --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2879 @@ -0,0 +1,2 @@ + +-smbios type=11,path=xxx results in buffer overrun due to missing null terminator diff --git a/results/classifier/deepseek-2/output/hypervisor/2881 b/results/classifier/deepseek-2/output/hypervisor/2881 new file mode 100644 index 000000000..76a89c3b3 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2885 b/results/classifier/deepseek-2/output/hypervisor/2885 new file mode 100644 index 000000000..e59de5e96 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2885 @@ -0,0 +1,2 @@ + +Unable to increase CPU's for existing RISCV VM diff --git a/results/classifier/deepseek-2/output/hypervisor/2886 b/results/classifier/deepseek-2/output/hypervisor/2886 new file mode 100644 index 000000000..23a8c39db --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2886 @@ -0,0 +1,16 @@ + +ACPI MADT advertises GITS even when disabled +Description of problem: +As per the command line given above, QEMU shall emulate a GICv4 without GIC Interrupt Translation Service (GITS). + +The following happens: +- ACPI **incorrectly** lists a GITS (type 0xf) structure in the MADT with GITS MMIO Base = 0x8080000 +- The OS reads that structure and interprets it to mean a GITS is present at the given MMIO address +- Subsequent access to GITS MMIO causes a data abort (0x25) because QEMU doesn't emulate a GITS (as requested) + +The bug is thus that QEMU wrongly advertises GITS as present (via the MADT) when it is in fact absent. +Steps to reproduce: +1. Disable GITS emulation by passing `its=off` on the QEMU command line +2. Check if a GITS structure is listed in the ACPI MADT (must be present in ACPI MADT only if GITS is enabled and absent otherwise) +Additional information: +When booting with `its=on` (default), everything works as expected. diff --git a/results/classifier/deepseek-2/output/hypervisor/2887 b/results/classifier/deepseek-2/output/hypervisor/2887 new file mode 100644 index 000000000..3303fc573 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2887 @@ -0,0 +1,2 @@ + +Qemu VM WHPX Startup Error with OVMF Code and VARS UEFI Files diff --git a/results/classifier/deepseek-2/output/hypervisor/2895 b/results/classifier/deepseek-2/output/hypervisor/2895 new file mode 100644 index 000000000..1475d5400 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2895 @@ -0,0 +1,31 @@ + +qemu-system-aarch64: Error: r = HV_BAD_ARGUMENT (0xfae94003, at ../target/arm/hvf/hvf.c:2259) +Description of problem: +When I launch a Linux guest in QEMU with `-accel hvf` + `-gdb "tcp::1234"`, and I try to debug the kernel with `lldb`, QEMU crashes with the following report: + +``` +qemu-system-aarch64: Error: r = HV_BAD_ARGUMENT (0xfae94003, at ../target/arm/hvf/hvf.c:2259) +``` +Steps to reproduce: +1. Run QEMU with `-accel hvf` + `-gdb "tcp::1234"` and a custom kernel (`-kernel Image`) +2. Try to attach using `lldb vmlinux` + `(lldb) gdb-remote 1234` +Additional information: +Debugging QEMU I see the crash is due to the `cpu->accel->fd` file descriptor being `0`: + +``` +warning: qemu-system-aarch64 was compiled with optimization - stepping may behave oddly; variables may not be available. +frame #4: 0x00000001003dd24c qemu-system-aarch64`hvf_arch_update_guest_debug [inlined] hvf_put_guest_debug_registers(cpu=0x0000000158118000) at hvf.c:2259:9 [opt] + 2256 for (i = 0; i < max_hw_bps; i++) { + 2257 r = hv_vcpu_set_sys_reg(cpu->accel->fd, dbgbcr_regs[i], + 2258 env->cp15.dbgbcr[i]); +-> 2259 assert_hvf_ok(r); + 2260 r = hv_vcpu_set_sys_reg(cpu->accel->fd, dbgbvr_regs[i], + 2261 env->cp15.dbgbvr[i]); + 2262 assert_hvf_ok(r); +(lldb) print cpu->accel->fd +(hvf_vcpuid) 0 +(lldb) print dbgbcr_regs[i] +(const uint16_t) 32773 +(lldb) print env->cp15.dbgbcr[i] +(uint64_t) 480 +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/2913 b/results/classifier/deepseek-2/output/hypervisor/2913 new file mode 100644 index 000000000..b8feda08d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2913 @@ -0,0 +1,2 @@ + +vmapple machine unusable with macOS 15.4 diff --git a/results/classifier/deepseek-2/output/hypervisor/2919 b/results/classifier/deepseek-2/output/hypervisor/2919 new file mode 100644 index 000000000..4b90b1be4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2919 @@ -0,0 +1,14 @@ + +qemu-ga update resetting VssOption Registry key to default +Description of problem: +Before I installed the .exe from iso `virtio-win-0.1.271.iso`, I had value 5 in registry key `HKLM:\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider\VssOption`. +After the driver update by the .exe, the value was set to 1. + +This registry key shouldn't change in driver update, as its value was manually set to 5 and it is important to preserve MSSQL backups in Proxmox. +Source: +https://blog.datact.ch/backup-mssql-server-with-proxmox +https://forum.proxmox.com/threads/pbs-breaking-customer-sql-backups-backups-without-fs-freeze.111526/ +Steps to reproduce: +1. Set a value to `HKLM:\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider\VssOption` other than 1. +2. Install the .exe from version 0.1.271. +3. Check the key value. diff --git a/results/classifier/deepseek-2/output/hypervisor/293 b/results/classifier/deepseek-2/output/hypervisor/293 new file mode 100644 index 000000000..4e2499367 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/293 @@ -0,0 +1,2 @@ + +Qemu SPARC64 Panics on Sun Solaris 5.8 - BOP_ALLOC failed diff --git a/results/classifier/deepseek-2/output/hypervisor/2933 b/results/classifier/deepseek-2/output/hypervisor/2933 new file mode 100644 index 000000000..189ce3db1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2933 @@ -0,0 +1,23 @@ + +After updating QEMU to 10.0, XNU kernel of OS X 10.8 throws kernel panic (type=0 divide error) +Description of problem: +Before updating to QEMU 10.0, my OS X 10.8 installation has worked pretty clear, but after QEMU update, XNU kernel now throws divide error during the boot. +Steps to reproduce: +1. Install OS X 10.8 on QEMU <10.0, for example 9.2.3. +2. Update QEMU to 10.0 version +3. Launch OS X +Additional information: +Screenshot of the issue: + + +OpenCore config (not changed before update, so above suspicion): +[config.plist](/uploads/4b80b60f9497e5ecd9237e4eeddcce8a/config.plist) + +Full OS X folder (without Installer.dmg): +[OS_X_10.8.zip](/uploads/1af6150869495a8f196e18d18127011b/OS_X_10.8.zip) + +How I've done Installer.dmg: +1. Go [here](https://updates.cdn-apple.com/2021/macos/031-0627-20210614-90D11F33-1A65-42DD-BBEA-E1D9F43A6B3F/InstallMacOSX.dmg) +2. `xar -xf` to .pkg +3. Show package contents to extracted .pkg +4. Here it is: InstallESD.dmg, which I've renamed to Installer.dmg diff --git a/results/classifier/deepseek-2/output/hypervisor/2938 b/results/classifier/deepseek-2/output/hypervisor/2938 new file mode 100644 index 000000000..0fdbfa716 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2943 b/results/classifier/deepseek-2/output/hypervisor/2943 new file mode 100644 index 000000000..cad0ece53 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2943 @@ -0,0 +1,8 @@ + +Please add a configurable for disabling, or by default disable, KVM_X86_QUIRK_IGNORE_GUEST_PAT on Intel host CPU +Additional information: +I am not familiar with QEMU code base or much programming in general. I did a quick grep through the latest QEMU sources pulled from this repository for the string `KVM_X86_QUIRK_IGNORE_GUEST_PAT`. It does not seem to occur anywhere which makes me think its existence and effect on QEMU users has gone unnoticed. + +If there is a handling of this flag which I have not noticed in the QEMU source code or documentation please guide me to where I can read about and probably configure it. + +Thank you. diff --git a/results/classifier/deepseek-2/output/hypervisor/2966 b/results/classifier/deepseek-2/output/hypervisor/2966 new file mode 100644 index 000000000..c563f92b8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2966 @@ -0,0 +1,28 @@ + +KVM: Failed to create TCE64 table for liobn 0x80000001 +Description of problem: +When rebooting the system we hit : + ``` + KVM: Failed to create TCE64 table for liobn 0x80000001 + qemu-system-ppc64: ../system/memory.c:2666: memory_region_add_subregion_common: Assertion `!subregion->container' failed. + Aborted (core dumped) + ``` +Steps to reproduce: +1. Start the machine +2. Reboot it + + ``` + curl -LO https://cloud.centos.org/centos/10-stream/ppc64le/images/CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 + export LIBGUESTFS_BACKEND=direct + virt-customize -v -a CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 --root-password password:centos + qemu-system-ppc64 --enable-kvm -m 4096 -smp 8 -hda CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 -vga none -nographic -device qemu-xhci + # once logged into it + systemctl reboot + [...] + KVM: Failed to create TCE64 table for liobn 0x80000001 + qemu-system-ppc64: ../system/memory.c:2666: memory_region_add_subregion_common: Assertion `!subregion->container' failed. + Aborted (core dumped) + ``` +Additional information: +The issue was already reported on ML https://lists.nongnu.org/archive/html/qemu-devel/2025-03/msg05137.html +I also hit that issue while building a CoreOS CentOS Stream 10 image https://github.com/openshift/os/issues/1818. I was able to validate that the commit https://github.com/torvalds/linux/commit/6aa989ab2bd0d37540c812b4270006ff794662e7 introduced the bug. diff --git a/results/classifier/deepseek-2/output/hypervisor/2975 b/results/classifier/deepseek-2/output/hypervisor/2975 new file mode 100644 index 000000000..4f92d9ad2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2975 @@ -0,0 +1,69 @@ + +qemu-system-x86_64: VFIO_MAP_DMA failed: -22 IVSHMEM +Description of problem: +QEMU do not run with looking glass KVMFR and with host model cpu +It only works when I set cpu to `Snowridge,vmx=on,fma=on,avx=on,f16c=on,hypervisor=on...` (you can see in kvm.sh) +Steps to reproduce: +1. I have a script ( search for 'WITH VFIO') +Additional information: +UPD +Some additional debug info from GDB + +``` +=== vfio_listener_region_add === +Arguments: +listener = 0x55555a4dd2f0 +section = 0x7fffedb389c0 + +Section details: + section->offset_within_address_space: 0x382000000000 + Memory region: 0x555558120dd0 + Memory region name: shmmem-shmem0 + Memory region size: 0x10000000 + Memory region addr: 0x382000000000 +Error accessing section details: There is no member named offset. + +=== vfio_get_section_iova_range ENTRY === +Arguments: +bcontainer = 0x55555a4dd2c0 +section = 0x7fffedb389c0 +out_iova = 0x7fffedb388b0 +out_end = 0x7fffedb388b8 +out_llend = 0x7fffedb38900 + +Local variables at entry: +llend = 140737181354144 +iova = 140737181354432 + +Thread 4 "CPU 0/KVM" hit Breakpoint -96, 0x0000555555b8511a in vfio_listener_region_add (listener=0x55555a4dd2f0, + section=0x7fffedb389c0) at ../../../hw/vfio/listener.c:467 +467 if (!vfio_get_section_iova_range(bcontainer, section, &iova, &end, +(gdb) +Continuing. +2025-05-20T22:46:27.819893Z qemu-system-x86_64: vfio_container_dma_map(0x55555a4dd2c0, 0x382000000000, 0x10000000, 0x7fffcffff000) = -22 (Invalid argument) +qemu: hardware error: vfio: DMA mapping failed, unable to continue +CPU #0: +RAX=00000000e0000000 RBX=00000000e0608004 RCX=0000000000608004 RDX=0000000000000003 +RSI=0000000000000003 RDI=0000000000000000 RBP=000000007ef6b640 RSP=000000007ef6b5f0 +R8 =0000000000000000 R9 =000000007ef6b70f R10=0000000000000000 R11=0000000000000004 +R12=000000007ef6b800 R13=0000000000000003 R14=0000000000000000 R15=000000007ef6b7fe +RIP=000000007e1fe2eb RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 + +``` + +Tested with latest QEMU 2af4a82ab2cce3412ffc92cd4c96bd870e33bc8e same error +``` +sudo dnf builddep qemu +../../../configure --enable-debug +``` + +[ERROR-QEMU-GIT-2af4a82ab2cce3412ffc92cd4c96bd870e33bc8e.txt](/uploads/060b26f091f0391f0491ea91dbe78f6d/ERROR-QEMU-GIT-2af4a82ab2cce3412ffc92cd4c96bd870e33bc8e.txt) + +[ERROR-trace-iova-values.txt](/uploads/22cacf4a5cb2c91ff6375c792a25dde1/ERROR-trace-iova-values.txt) + +[WORKINg-trace-iova-values.txt](/uploads/d4d53c2e743cf5f2d5bf810d61b9f1e6/WORKINg-trace-iova-values.txt) + + +[kvm.log.txt](/uploads/ac31eebf6e63aa6abe2498d1a4064bef/kvm.log.txt) + +[kvm.sh](/uploads/7f656f7cf0d623a240309ee61b024dc9/kvm.sh) diff --git a/results/classifier/deepseek-2/output/hypervisor/2976 b/results/classifier/deepseek-2/output/hypervisor/2976 new file mode 100644 index 000000000..db292d20f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2976 @@ -0,0 +1,26 @@ + +attach-ns doesn't work correctly in SR-IOV, cannot attach NS to VF if it is attached to a PF +Description of problem: +We can't attach namespace to a VF (Secondary controller) unless it is not attached to a primary controller first + +Lately in the commit https://github.com/qemu/qemu/commit/6ccca4b6bb9f994cc04e71004e1767a3476d2b23 the file qemu/hw/nvme/ctrl.c got changed -\> in function "nvme_ns_attachment" -\> line 6819 (At the time I'm writing the bug) which is the condation in attach ns to check if the namespace is attached "`if (nvme_ns(n, nsid)) {`" + +This change will always result in checking the namespace attach to the PF even if we are trying to attach it to the VF. +Steps to reproduce: +1. Enable a VF: + +``` +echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset +sleep 1 + +echo 2 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs +sleep 1 + +nvme virt-mgmt /dev/nvme0 -c 1 -r 1 -a 8 -n 1 +nvme virt-mgmt /dev/nvme0 -c 1 -r 0 -a 8 -n 2 +nvme virt-mgmt /dev/nvme0 -c 1 -a 9 +sleep 1 +``` + +2. attach namespace 1 to the PF (e.g. `vme attach-ns /dev/nvme0 -n1 -c0` ) +3. try to attach it using the nvme_cli command from the PF (e.g. `nvme attach-ns /dev/nvme0 -n1 -c1`) diff --git a/results/classifier/deepseek-2/output/hypervisor/2977 b/results/classifier/deepseek-2/output/hypervisor/2977 new file mode 100644 index 000000000..ab4d0e2f6 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2981 b/results/classifier/deepseek-2/output/hypervisor/2981 new file mode 100644 index 000000000..6fb71a41e --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2984 b/results/classifier/deepseek-2/output/hypervisor/2984 new file mode 100644 index 000000000..09d9fdcdf --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/2986 b/results/classifier/deepseek-2/output/hypervisor/2986 new file mode 100644 index 000000000..84caa4543 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/2986 @@ -0,0 +1,2 @@ + +ARM register DBGDTR_EL0 incorrectly causes undefined exception diff --git a/results/classifier/deepseek-2/output/hypervisor/300 b/results/classifier/deepseek-2/output/hypervisor/300 new file mode 100644 index 000000000..68b1d6e5f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/300 @@ -0,0 +1,2 @@ + +qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached failed again diff --git a/results/classifier/deepseek-2/output/hypervisor/301 b/results/classifier/deepseek-2/output/hypervisor/301 new file mode 100644 index 000000000..039093335 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/301 @@ -0,0 +1,2 @@ + +Assertion `addr < cache->len && 2 <= cache->len - addr' in virtio-blk diff --git a/results/classifier/deepseek-2/output/hypervisor/302 b/results/classifier/deepseek-2/output/hypervisor/302 new file mode 100644 index 000000000..eab667f0f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/302 @@ -0,0 +1,2 @@ + +[Fuzz] qemu-system-i386 virtio-mouse: Assertion in address_space_lduw_le_cached failed diff --git a/results/classifier/deepseek-2/output/hypervisor/310 b/results/classifier/deepseek-2/output/hypervisor/310 new file mode 100644 index 000000000..eda290ba6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/310 @@ -0,0 +1,2 @@ + +unable to migrate non shared storage when TLS is used diff --git a/results/classifier/deepseek-2/output/hypervisor/337 b/results/classifier/deepseek-2/output/hypervisor/337 new file mode 100644 index 000000000..ca763ad03 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/337 @@ -0,0 +1,2 @@ + +QEMU emulator version 6.0.50 Failure with nested FreeBSD bhyve diff --git a/results/classifier/deepseek-2/output/hypervisor/340 b/results/classifier/deepseek-2/output/hypervisor/340 new file mode 100644 index 000000000..c3917a693 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/340 @@ -0,0 +1,2 @@ + +qemu: uncaught target signal 6 (Aborted) - core dumped on Apple Silicon M1 arm64 diff --git a/results/classifier/deepseek-2/output/hypervisor/343 b/results/classifier/deepseek-2/output/hypervisor/343 new file mode 100644 index 000000000..db6ba618f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/343 @@ -0,0 +1,2 @@ + +madvise reports success, but doesn't implement WIPEONFORK. diff --git a/results/classifier/deepseek-2/output/hypervisor/344 b/results/classifier/deepseek-2/output/hypervisor/344 new file mode 100644 index 000000000..3ccb6f6de --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/344 @@ -0,0 +1,2 @@ + +Option "-loadvm" cannot load VM snapshot, created from QMP API diff --git a/results/classifier/deepseek-2/output/hypervisor/355410 b/results/classifier/deepseek-2/output/hypervisor/355410 new file mode 100644 index 000000000..618fa28a3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/355410 @@ -0,0 +1,32 @@ + +kvm crashed with SIGSEGV in malloc_consolidate() + +Binary package hint: kvm + +See Bug #355401. Oddly enough, when Windows tries to install drivers for a WDM device (a W380a on USB), kvm crashes. + +ProblemType: Crash +Architecture: amd64 +DistroRelease: Ubuntu 9.04 +ExecutablePath: /usr/bin/kvm +KvmCmdLine: Error: command ['ps', '-p', '5036', '-F'] failed with exit code 1: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD +MachineType: ASUSTeK Computer Inc. F3Sa +NonfreeKernelModules: fglrx +Package: kvm 1:84+dfsg-0ubuntu10 +ProcCmdLine: root=UUID=1b4d3e6f-e7de-4dda-a22b-4ee8d3da378d ro splash +ProcCmdline: kvm -snapshot -net nic,model=ne2k_pci -net user -soundhw es1370 -usb -usbdevice tablet -m 256 winXP.SP3-IE7-20081018.qcow -usbdevice host:0fce:d0b5 -smb /home/username/temp/Unlock_Sony_Ericsson/ +ProcEnviron: + PATH=(custom, user) + LANG=en_CA.UTF-8 + SHELL=/bin/bash +ProcVersionSignature: Ubuntu 2.6.28-11.40-generic +Signal: 11 +SourcePackage: kvm +StacktraceTop: + malloc_consolidate (av=0x7fe3b0607a00) at malloc.c:4897 + _int_malloc (av=0x7fe3b0607a00, bytes=2128) + *__GI___libc_malloc (bytes=2128) at malloc.c:3551 + ?? () + ?? () +Title: kvm crashed with SIGSEGV in malloc_consolidate() +UserGroups: adm admin audio cdrom dialout dip disk fax fuse kvm lpadmin netdev plugdev sambashare scanner tape video \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/362 b/results/classifier/deepseek-2/output/hypervisor/362 new file mode 100644 index 000000000..6175022b5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/362 @@ -0,0 +1,2 @@ + +check of PMR capability is missing for PMRCTL register write diff --git a/results/classifier/deepseek-2/output/hypervisor/380 b/results/classifier/deepseek-2/output/hypervisor/380 new file mode 100644 index 000000000..a6acd68fa --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/380 @@ -0,0 +1,2 @@ + +Windows 7 fails to boot diff --git a/results/classifier/deepseek-2/output/hypervisor/384 b/results/classifier/deepseek-2/output/hypervisor/384 new file mode 100644 index 000000000..6337db118 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/384 @@ -0,0 +1,2 @@ + +qemu-monitor-event command gets stuck randomly diff --git a/results/classifier/deepseek-2/output/hypervisor/393 b/results/classifier/deepseek-2/output/hypervisor/393 new file mode 100644 index 000000000..d9077d2e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/393 @@ -0,0 +1,2 @@ + +tests/vm: Warn when cross-build VM is run with TCG accelerator diff --git a/results/classifier/deepseek-2/output/hypervisor/412 b/results/classifier/deepseek-2/output/hypervisor/412 new file mode 100644 index 000000000..4f3f65af4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/412 @@ -0,0 +1,2 @@ + +stable-5.0 crashes with SIGSEV while checking for kvm extension diff --git a/results/classifier/deepseek-2/output/hypervisor/430 b/results/classifier/deepseek-2/output/hypervisor/430 new file mode 100644 index 000000000..895445399 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/430 @@ -0,0 +1,2 @@ + +Microsoft Hyper-V acceleration not working diff --git a/results/classifier/deepseek-2/output/hypervisor/438 b/results/classifier/deepseek-2/output/hypervisor/438 new file mode 100644 index 000000000..42c55dafa --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/438 @@ -0,0 +1,2 @@ + +[alpha] FEN bit not honored in system mode diff --git a/results/classifier/deepseek-2/output/hypervisor/439 b/results/classifier/deepseek-2/output/hypervisor/439 new file mode 100644 index 000000000..0a0f0fd5e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/439 @@ -0,0 +1,2 @@ + +Hard crash - qemu-6.0.0 with windows 10 guest diff --git a/results/classifier/deepseek-2/output/hypervisor/443 b/results/classifier/deepseek-2/output/hypervisor/443 new file mode 100644 index 000000000..9679a45b9 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/443 @@ -0,0 +1,2 @@ + +QEMU on Windows aarch64 diff --git a/results/classifier/deepseek-2/output/hypervisor/447 b/results/classifier/deepseek-2/output/hypervisor/447 new file mode 100644 index 000000000..01e4a7ab4 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/447 @@ -0,0 +1,2 @@ + +qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option) diff --git a/results/classifier/deepseek-2/output/hypervisor/467 b/results/classifier/deepseek-2/output/hypervisor/467 new file mode 100644 index 000000000..bacf68edd --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/467 @@ -0,0 +1,2 @@ + +savevm/loadvm/migration broken for 32-bit arm guests that use TrustZone diff --git a/results/classifier/deepseek-2/output/hypervisor/479 b/results/classifier/deepseek-2/output/hypervisor/479 new file mode 100644 index 000000000..6c6f5308a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/479 @@ -0,0 +1,13 @@ + +qemu-6.0.0: Assertion 'p_rcu_reader->depth != 0' failed +Description of problem: +assertion failure: +``` +qemu-system-aarch64: /home/aileen/Downloads/qemu-6.0.0/include/qemu/rcu.h:93: rcu_read_unlock: Assertion `p_rcu_reader->depth != 0' failed. +``` +Steps to reproduce: +1. You cannot +2. unless I give +3. you the ELF file. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/482 b/results/classifier/deepseek-2/output/hypervisor/482 new file mode 100644 index 000000000..a75197794 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/482 @@ -0,0 +1,2 @@ + +Unable to set SVE VL to 1024 bits or above since 7b6a2198 diff --git a/results/classifier/deepseek-2/output/hypervisor/485239 b/results/classifier/deepseek-2/output/hypervisor/485239 new file mode 100644 index 000000000..24b273137 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/485239 @@ -0,0 +1,21 @@ + +Windows 2008 datacenter- 64 bit , installation fails with qemu-system-x86_64 0.11.50 + +Installation of Windows 2008 datacenter- 64 bit fails with qemu-system-x86_64. +Version of qemu-system-x86_64 is 0.11.50. +The installation source is dvd iso. Just after booting for installation of the Windows guest, it hangs for sometime and then the installation crashes with the error: + +"A problem has been detected and windows has been shut down to prevent damage to your computer". + +Below is the command used for creating the guest. +/usr/local/bin/qemu-system-x86_64 -cdrom /home/en_windows_server_2008_datacenter_enterprise_standard_x64_dvd_X14-26714.iso -hda /var/lib/libvirt/images/win2008_dc_64.qcow2 -m 3000 -smp 3 -net nic -net tap,script=/home/qemu-ifup-latest -name win2008_dc_64 -vnc :1 & + +Disk info of the guest image is as below: +/usr/local/bin/qemu-img info /var/lib/libvirt/images/win2008_dc_64.qcow2 +image: /var/lib/libvirt/images/win2008_dc_64.qcow2 +file format: qcow2 +virtual size: 15G (16106127360 bytes) +disk size: 136K +cluster_size: 65536 + +This issue is also reproducible with raw image format. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/498035 b/results/classifier/deepseek-2/output/hypervisor/498035 new file mode 100644 index 000000000..68aca3737 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/498035 @@ -0,0 +1,8 @@ + +qemu hangs on shutdown or reboot (XP guest) + +When I shut down or reboot my Windows XP guest, about half the time, it hangs at the point where it says "Windows is shutting down...". At that point qemu is using 100% of one host CPU, about 85% user, 15% system. (Core 2 Quad 2.66GHz) + +This is the command line I use to start qemu: + +qemu-system-x86_64 -hda winxp.img -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -boot c -enable-kvm & \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/513 b/results/classifier/deepseek-2/output/hypervisor/513 new file mode 100644 index 000000000..6ced9a17a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/513 @@ -0,0 +1,2 @@ + +Qemu/WHPX fails on applying UEFI firmware with -pflash diff --git a/results/classifier/deepseek-2/output/hypervisor/518 b/results/classifier/deepseek-2/output/hypervisor/518 new file mode 100644 index 000000000..fbd9cb335 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/518 @@ -0,0 +1,2 @@ + +Android for arm guest diff --git a/results/classifier/deepseek-2/output/hypervisor/524447 b/results/classifier/deepseek-2/output/hypervisor/524447 new file mode 100644 index 000000000..7302300bf --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/524447 @@ -0,0 +1,10 @@ + +virsh save is very slow + +As reported here: http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html + +"virsh save" is very slow - it writes the image at around 1MB/sec on my test system. + +(I think I saw a bug report for this issue on Fedora's bugzilla, but I can't find it now...) + +Confirmed under Karmic. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/525 b/results/classifier/deepseek-2/output/hypervisor/525 new file mode 100644 index 000000000..1d4ec2199 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/525 @@ -0,0 +1,15 @@ + +missing features with CPU `qemu64` +Description of problem: +The live migration complains about a missing feature when using the CPU qemu64, which is _guaranteed to work_. +Steps to reproduce: +1. start the VM with qemu64 on the CPU: Intel(R) Xeon(R) CPU E5-2620 v4 +2. live-migrate the VM to a CPU: Intel(R) Xeon(R) CPU E5-2670 0 +Additional information: +The migration fails: +``` +root@covid21:~# virsh migrate --verbose --live --persistent --undefinesource myvm.local qemu+ssh://covid24/system +error: operation failed: guest CPU doesn't match specification: missing features: abm +``` + +This should not happen on a generic CPU, which should always work. Note, that the migration succeeds when using `-cpu qemu64,abm=off …` diff --git a/results/classifier/deepseek-2/output/hypervisor/526653 b/results/classifier/deepseek-2/output/hypervisor/526653 new file mode 100644 index 000000000..200bcede2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/526653 @@ -0,0 +1,39 @@ + +Breakpoint on Memory address fails with KVM + +Using QEMU version 0.12.50 under ubuntu Karmic x64 + +To reproduce the error using a floppy with a bootloder: +qemu-system-x86_64 -s -S -fda floppy.img -boot a -enable-kvm + +connect with gdb: +(gdb) set arch i8086 +The target architecture is assumed to be i8086 +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +0x0000fff0 in ?? () +(gdb) break *0x7c00 +Breakpoint 1 at 0x7c00 +(gdb) continue +Continuing. + +The breakpoint is not hit. + +If you close qemu and start it without kvm support: + +qemu-system-x86_64 -s -S -fda floppy.img -boot a + +(gdb) set arch i8086 +The target architecture is assumed to be i8086 +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +0x0000fff0 in ?? () +(gdb) break *0x7c00 +Breakpoint 1 at 0x7c00 +(gdb) continue +Continuing. + +Breakpoint 1, 0x00007c00 in ?? () +(gdb) + +The breakpoint is hit. If you wait until after the bootloader has been loaded into memory, you can properly set breakpoints with or without kvm enabled. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/528 b/results/classifier/deepseek-2/output/hypervisor/528 new file mode 100644 index 000000000..81777c0fe --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/528 @@ -0,0 +1,2 @@ + +arm: trying to use KVM with an EL3-enabled CPU hits an assertion failure diff --git a/results/classifier/deepseek-2/output/hypervisor/530 b/results/classifier/deepseek-2/output/hypervisor/530 new file mode 100644 index 000000000..690327963 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/530 @@ -0,0 +1,44 @@ + +Invalid guest state when rebooting a nesting hypervisor +Description of problem: +On a standard Linux machine, I run a custom hypervisor stack based on [Hedron](https://github.com/cyberus-technology/hedron) in a qemu VM with nesting capabilities. The Hedron stack starts a nested Linux guest with complete pass-through of all resources not required for virtualizing the nested guest. In particular, ACPI and PCI including the reset functionality are directly accessible to the nested guest. As soon as the nested guest issues a machine reset, I get a hardware error with the following error message: + +<details><summary>KVM: entry failed, hardware error 0x80000021</summary> +<pre> +If you're running a guest on an Intel machine without unrestricted mode +support, the failure can be most likely due to the guest entering an invalid +state for Intel VT. For example, the guest maybe running in big real mode +which is not supported on less recent Intel processors. + +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00050657 +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=003726f8 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +</pre> +</details> + +If I'm not mistaken, the CR4 value of `0x003726f8` is the offending state here, because PCIDE (bit 17) is set, even though the arch state indicates real-mode and the Intel SDM states: + +> If the “IA-32e mode guest” VM-entry control is 0, bit 17 in the CR4 field (corresponding to CR4.PCIDE) must be 0. + +Furthermore, the issue is not present when not using PCID in the L1 hypervisor or when PCID/VPID are fused out using `qemu-kvm -cpu host,-pcid,-vmx-vpid,-vmx-invpcid-exit`. +Steps to reproduce: +1. Boot custom hypervisor stack (unfortunately not yet publicly available, I'm working on that) +2. In nested Linux guest, type `reboot`, which eventually directly reboots the main VM (all main VM hardware is passed through to the single nested guest) +Additional information: +I have tracked down the [change](https://gitlab.com/qemu/qemu/-/commit/b16c0e20c74218f2d69710cedad11da7dd4d2190#063d8f78716c7a658841a1d51cc66bf30f697082_3920_3944) that likely introduced this issue. Moving the call to `kvm_put_sregs` back down (I suspect after `kvm_put_nested_state`, but I did not verify that yet) solves the reboot issue for me. The comment makes it clear that it is important to keep a certain order here, so I'm aware just reversing it is not an option. + +Maybe this already helps enough to figure out what exactly the issue and correct fix is, and I am happy to try any suggestions as long as I cannot provide a proper reproducer. diff --git a/results/classifier/deepseek-2/output/hypervisor/538 b/results/classifier/deepseek-2/output/hypervisor/538 new file mode 100644 index 000000000..3bd01de67 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/538 @@ -0,0 +1,2 @@ + +Memory Leak in hpet_timer results in unusable machine diff --git a/results/classifier/deepseek-2/output/hypervisor/538808 b/results/classifier/deepseek-2/output/hypervisor/538808 new file mode 100644 index 000000000..da711647f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/538808 @@ -0,0 +1,12 @@ + +qemu-system-x86_64 0.12.2 crashes with -m 967 under Windows + +qemu 0.12.2 and 0.12.3 exit silently under Windows XP when using an -m value higher than 967. Any value below 967 works fine. Affects both qemu.exe and qemu-system-x86_64.exe (the only binaries currently available). +qemu 0.12.3 under Linux (Ubuntu 8.10) works fine. +Version 0.9.0 for Windows does not have this problem. I do not have any other binaries to test. + +Command used: +qemu-system-x86_64 -L . -m 967 -hda linux.img -localtime -M pc + +There is plenty of available RAM on the host PC (see attached systeminfo). +Not sure what debugging options to use, but will attach whatever is necessary. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/554 b/results/classifier/deepseek-2/output/hypervisor/554 new file mode 100644 index 000000000..921944102 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/554 @@ -0,0 +1,2 @@ + +q35 machine type cdrom device not discovered by freedos diff --git a/results/classifier/deepseek-2/output/hypervisor/561 b/results/classifier/deepseek-2/output/hypervisor/561 new file mode 100644 index 000000000..9a1d32fe7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/561 @@ -0,0 +1,2 @@ + +Q35 - ACPI PCI hot-plug issue with Windows guest diff --git a/results/classifier/deepseek-2/output/hypervisor/573 b/results/classifier/deepseek-2/output/hypervisor/573 new file mode 100644 index 000000000..e681d706f --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/573 @@ -0,0 +1,2 @@ + +maybe-uninitialized warning in pnv_phb3_translate_iommu() diff --git a/results/classifier/deepseek-2/output/hypervisor/584514 b/results/classifier/deepseek-2/output/hypervisor/584514 new file mode 100644 index 000000000..dbe75c63b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/584514 @@ -0,0 +1,29 @@ + +Qemu-KVM 0.12.4 Guest entered Paused State + +I recently had a 0.12.4 qemu-kvm with a debian lenny guest which occasionally paused. + +There was no memory exhaustion as suggested earlier. + +qemu-kvm send the following output:: + +VM internal error. Suberror: 1 +rax 0000000000000100 rbx ffff880017585bc0 rcx 00007f84c6d5b000 rdx 0000000000000001 +rsi 0000000000000000 rdi ffff88001d322dec rsp ffff88001e133e88 rbp ffff88001e133e88 +r8 0000000001f25bc2 r9 0000000000000007 r10 00007f84c6b4d97b r11 0000000000000206 +r12 ffff88001d322dec r13 ffff88001d322de8 r14 0000000000000001 r15 0000000000000000 +rip ffffffff81039719 rflags 00010092 +cs 0010 (00000000/ffffffff p 1 dpl 0 db 0 s 1 type b l 1 g 1 avl 0) +ds 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +es 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +ss 0018 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) +fs 0000 (7f84c6d53700/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +gs 0000 (ffff880001d00000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +tr 0040 (ffff880001d13780/00002087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) +ldt 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +gdt ffff880001d04000/7f +idt ffffffff8195e000/fff +cr0 80050033 cr2 7f84c6b38ec8 cr3 1db7d000 cr4 6e0 cr8 0 efer 501 +emulation failure, check dmesg for details + +Unfortunately, I found nothing in syslog or dmesg \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/585 b/results/classifier/deepseek-2/output/hypervisor/585 new file mode 100644 index 000000000..d94ba0e9d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/585 @@ -0,0 +1,2 @@ + +mret trigger exception when pmp equals false diff --git a/results/classifier/deepseek-2/output/hypervisor/587 b/results/classifier/deepseek-2/output/hypervisor/587 new file mode 100644 index 000000000..349caaac8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/587 @@ -0,0 +1,2 @@ + +qemu show no error but the virtual machine stuck in boot (GPU passthrough) diff --git a/results/classifier/deepseek-2/output/hypervisor/589 b/results/classifier/deepseek-2/output/hypervisor/589 new file mode 100644 index 000000000..79c496f86 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/589 @@ -0,0 +1,2 @@ + +Error installing QGA file under virtual machine of windows system diff --git a/results/classifier/deepseek-2/output/hypervisor/599958 b/results/classifier/deepseek-2/output/hypervisor/599958 new file mode 100644 index 000000000..eebedad54 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/599958 @@ -0,0 +1,43 @@ + +Timedrift problems with Win7: hpet missing time drift fixups + +We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing + +kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load FAIL 1 Time drift too large after rest period: 38.63% +kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL 1 Time drift too large at iteration 1: 17.77 seconds +kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration FAIL 1 Time drift too large at iteration 2: 3.08 seconds + +Steps to reproduce: + +timedrift.with_load + +1) Log into a guest. +2) Take a time reading from the guest and host. +3) Run load on the guest and host. +4) Take a second time reading. +5) Stop the load and rest for a while. +6) Take a third time reading. +7) If the drift immediately after load is higher than a user- + specified value (in %), fail. + If the drift after the rest period is higher than a user-specified value, + fail. + +timedrift.with_migration + +1) Log into a guest. +2) Take a time reading from the guest and host. +3) Migrate the guest. +4) Take a second time reading. +5) If the drift (in seconds) is higher than a user specified value, fail. + +timedrift.with_reboot + +1) Log into a guest. +2) Take a time reading from the guest and host. +3) Reboot the guest. +4) Take a second time reading. +5) If the drift (in seconds) is higher than a user specified value, fail. + +This bug is to register those issues and keep an eye on them. + +Attached, some logs from the autotest tests executed on the guest \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/601 b/results/classifier/deepseek-2/output/hypervisor/601 new file mode 100644 index 000000000..0bef3f732 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/603 b/results/classifier/deepseek-2/output/hypervisor/603 new file mode 100644 index 000000000..efd6039e0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/603 @@ -0,0 +1,2 @@ + +Unable to use mps2-an386 machine with qemu-6.0.0 version code diff --git a/results/classifier/deepseek-2/output/hypervisor/616 b/results/classifier/deepseek-2/output/hypervisor/616 new file mode 100644 index 000000000..bab55454a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/616 @@ -0,0 +1,108 @@ + +overflow condition code determined incorrectly after addition on s390x +Description of problem: +The following program foo.c +[foo.c](/uploads/78f5f799af6e3c400a6a42634f3f0e63/foo.c) + +``` +#include <stdio.h> + +int overflow_32 (int x, int y) +{ + int sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int overflow_64 (long long x, long long y) +{ + long sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int a1 = -2147483648; +int b1 = -2147483648; +long long a2 = -9223372036854775808L; +long long b2 = -9223372036854775808L; + +int main () +{ + { + int a = a1; + int b = b1; + printf ("a = 0x%x, b = 0x%x\n", a, b); + printf ("no_overflow = %d\n", overflow_32 (a, b)); + } + { + long long a = a2; + long long b = b2; + printf ("a = 0x%llx, b = 0x%llx\n", a, b); + printf ("no_overflow = %d\n", overflow_64 (a, b)); + } +} +``` + +should print + +``` +a = 0x80000000, b = 0x80000000 +no_overflow = 0 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 0 +``` + +However, when compiled as an s390x program and executed through +qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. + +``` +$ s390x-linux-gnu-gcc-10 --version +s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 +``` + +``` +$ s390x-linux-gnu-gcc-10 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +``` +$ s390x-linux-gnu-gcc-10 -O2 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the +'o' (overflow / ones) condition code: + +``` +overflow_64: + lgr %r1,%r2 ;; copy a into %r1 + lghi %r2,0 + agr %r1,%r3 ;; add a and b + bnor %r14 ;; if no overflow, return %r2 = 0 + lghi %r2,1 + br %r14 ;; otherwise, return %r2 = 1 +``` + +Either the bug is in GCC, that is, GCC produces code that uses the CPU's +overflow condition code when it shouldn't. + +Or the bug is in QEMU, that is, QEMU does not set the overflow condition +code correctly. + +This can be decided by running the above program on real Linux/s390x hardware +(to which I don't have access). +Steps to reproduce: +[foo.static.s390x](/uploads/ac41abf4c54baf9ca96ba82d75a24ad6/foo.static.s390x) +(foo.static.s390x is attached, the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") + +1. `qemu-s390x foo.static.s390x` +Additional information: +If the bug is really in QEMU, the attached patch fixes it. + +[0001-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/552917079ccd25f1861d682fc9dee3e8/0001-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/deepseek-2/output/hypervisor/616769 b/results/classifier/deepseek-2/output/hypervisor/616769 new file mode 100644 index 000000000..6bbe5aa19 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/616769 @@ -0,0 +1,28 @@ + +interrupt problem x86_64 + +Hello. +I'm studing the x86_64 arch to port colinux to this new architecture. + +For who does not know, colinux is a port of linux that runs on windows NATIVELY. Colinux is +1) a small windows driver +2) a kernel patched +3) some windows user-space application that talk with linux kernel (network, console, ...) + +I have written the more internal part of colinux, that is the code that switch between windows and linux. +This is done saving and restore the machine state : +1) CR3 +2) IDT +3) registers + +The problem I see is that after the switch I see the reboot of my virtual machine. +I would say that the new IDT and/or CR3 is not flushed. +My code is written in asm/C so I can follow the code step by step. +I can say exactly the instruction that is broken. + +All my code runs nicely on bochs. +I don't have an x86_64 real PC. + +If someone wants to repair this bug .... I'm here. + +Paolo Minazzi \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/623 b/results/classifier/deepseek-2/output/hypervisor/623 new file mode 100644 index 000000000..c54982c45 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/637 b/results/classifier/deepseek-2/output/hypervisor/637 new file mode 100644 index 000000000..81ef0bb85 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/64 b/results/classifier/deepseek-2/output/hypervisor/64 new file mode 100644 index 000000000..e386530c1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/64 @@ -0,0 +1,2 @@ + +raspi3 machine can not shutdown diff --git a/results/classifier/deepseek-2/output/hypervisor/645524 b/results/classifier/deepseek-2/output/hypervisor/645524 new file mode 100644 index 000000000..b375138ee --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/645524 @@ -0,0 +1,4 @@ + +No picture from USB webcam (kvm 0.13-rc1) + +I export my Linux webcam to KVM using the switches "-usb -usbdevice host:046d:0929". The XP guest sees the webcam and the drivers install, but the camera only shows a black image. When I open the camera in Windows Explorer, it says "0 images" and a black image, while on a real XP, it says "1 image" and shows the video from the camera. Same problem with different webcams. Same cameras work fine on a native XP install. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/649 b/results/classifier/deepseek-2/output/hypervisor/649 new file mode 100644 index 000000000..90a36810a --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/650 b/results/classifier/deepseek-2/output/hypervisor/650 new file mode 100644 index 000000000..2abb430ed --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/650 @@ -0,0 +1,25 @@ + +Monitor device_add triggers deadlock when calling drain_call_rcu on QEMU >= 6.0.0 +Description of problem: +It hangs +Steps to reproduce: +1. Run the QEMU: + ``` + ./qemu-system-mips64 -nographic + ``` +2. Enter into the QEMU monitor: press ctrl-a c +3. Execute command `device_add` without arguments: +``` +(qemu) device_add +``` +4. It hangs so bad that only `kill -9` helps +Additional information: +I didn't test versions between 4.2.0 and 6.0.0, but I can confirm that 6.0.0, 6.1.0 and the latest master pull have this bug, while version 4.2.0 doesn't have it. + +I've tracked the problem and found this. + +1. Command `device_add` calls function `drain_call_rcu`. `drain_call_rcu` waits indefinitely for drain_complete_event. +2. Function `cpu_exec` in accel/tcg/cpu-exec.c calls `rcu_read_lock` but does not call `rcu_read_unlock()`. `cpu_exec` just spins in its inner loop. +3. Function `call_rcu_thread` hanged in calling the `synchronize_rcu` which calls `wait_for_readers`. + +If I execute `stop` command in QEMU monitor before calling `device_add` command, no hang happen. diff --git a/results/classifier/deepseek-2/output/hypervisor/655 b/results/classifier/deepseek-2/output/hypervisor/655 new file mode 100644 index 000000000..3bc6a0889 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/655 @@ -0,0 +1,33 @@ + +Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8' +Description of problem: +The `java` command fails with the following message: + +```console +$ /usr/lib/jvm/java-17-openjdk-s390x/bin/java --version +# +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x000003ff9e4fe6f4, pid=2883, tid=2884 +# +# JRE version: (17.0+35) (build ) +# Java VM: OpenJDK 64-Bit Server VM (17+35-Ubuntu-120.04, mixed +# mode, sharing, tiered, compressed oops, compressed class ptrs, +# serial gc, linux-s390x) +# Problematic frame: +# C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8 +# +# Core dump will be written. Default location: Core dumps may +# be processed with "/usr/share/apport/apport %p %s %c %d %P %E" +# (or dumping to /home/ubuntu/core.2883) +# +# An error report file with more information is saved as: +# /home/ubuntu/hs_err_pid2883.log +# +# +Aborted (core dumped) +``` +Steps to reproduce: +1. Run `java --version` +Additional information: +The corresponding log file is attached as the file [hs_err_pid2883.log](/uploads/1631b6a0f0aad2f77c4928ed6bb540c6/hs_err_pid2883.log). diff --git a/results/classifier/deepseek-2/output/hypervisor/661 b/results/classifier/deepseek-2/output/hypervisor/661 new file mode 100644 index 000000000..cc6ea2637 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/661 @@ -0,0 +1,45 @@ + +Unable to enable 5 level paging +Description of problem: +When attempting to set cr4.LA57, qemu just freezes on that instruction. When I say freeze I mean literally freeze, no exceptions, nothing, it just halts forever on that instruction. When this happened, the first thing I did was + +``` +(qemu) info registers +EAX=00001000 EBX=00000001 ECX=80224f08 EDX=00000000 +ESI=8034a3a0 EDI=00026520 EBP=000079f8 ESP=000079c8 +EIP=00019648 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0020 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0018 00000000 ffffffff 00c09a00 DPL=0 CS32 [-R-] +SS =0020 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0020 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0020 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0020 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 0000e120 00000037 +IDT= 00000000 00000000 +CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +... +``` + +then using gdb to figure out what instruction it is hanging on, I set a breakpoint at 0x19648 at and ran +``` +(gdb) x/1 0x19648 +=> 0x19648: mov %rax,%cr4 +(gdb) +``` + +This instruction corresponds to this LOC within limine https://github.com/limine-bootloader/limine/blob/trunk/stage23/protos/stivale.32.c#L33 +Steps to reproduce: +1. Try to enable 5 level paging +2. qemu freezes when trying to set cr4.LA57 +3. cry +Additional information: +This never happened prior to version 6.1, I test this on multiple different machines and a few of my friends +experienced the same issue + +I have not tested this on linux, however I assume it will do the same on anything else. +Either way, qemu should not be just halting diff --git a/results/classifier/deepseek-2/output/hypervisor/664 b/results/classifier/deepseek-2/output/hypervisor/664 new file mode 100644 index 000000000..dcb67192d --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/677 b/results/classifier/deepseek-2/output/hypervisor/677 new file mode 100644 index 000000000..6cb35dae1 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/677 @@ -0,0 +1,2 @@ + +Qemu crashes when trying to load kernel inside of WSL2 diff --git a/results/classifier/deepseek-2/output/hypervisor/68 b/results/classifier/deepseek-2/output/hypervisor/68 new file mode 100644 index 000000000..f8e82fa05 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/68 @@ -0,0 +1,2 @@ + +Solaris can't be powered off with ACPI shutdown/poweroff diff --git a/results/classifier/deepseek-2/output/hypervisor/680758 b/results/classifier/deepseek-2/output/hypervisor/680758 new file mode 100644 index 000000000..d5f1b5a06 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/680758 @@ -0,0 +1,32 @@ + +balloon only resizes by 2M + +when in monitor and running balloon 512 from a 1024M VM, the vm dropped the size to 1020 (this value changes), then every subsequent request to balloon 512 will drop it by another 2M. The system was running at above 60% RAM free when these requests were made. also requesting to up the ram results in no change above 1024 (I'm guessing this is intentional, but was unable to find any documentation) + +Versions: + +qemu-kvm 0.13.0 +qemu-kvm.git b377474e589e5a1fe2abc7b13fafa8bad802637a + + +Qemu Command Line: + +./x86_64-softmmu/qemu-system-x86_64 -ees/seven.base,if=virtio -net nic,model=virtio,macaddr=02:00:00:00:00:01 -net tap,script=/etc/qemu/qemu-ifup,downscript=/etc/qemu/qemu-ifdown -vga std -usb -usbdevice tablet -rtc base=localtime,clock=host -watchdog i6300esb -balloon virtio -m 1024 -no-quit -smp 2 -monitor stdio + + +Monitor Session: + +QEMU 0.13.50 monitor - type 'help' for more information +(qemu) info balloon +balloon: actual=1024 +(qemu) balloon 1536 +(qemu) info balloon +balloon: actual=1024 +(qemu) balloon 512 +(qemu) info balloon +balloon: actual=1020 +(qemu) info balloon +balloon: actual=1020 +(qemu) balloon 512 +(qemu) info balloon +balloon: actual=1018 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/681 b/results/classifier/deepseek-2/output/hypervisor/681 new file mode 100644 index 000000000..d283db35e --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/682360 b/results/classifier/deepseek-2/output/hypervisor/682360 new file mode 100644 index 000000000..41e3b97c2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/682360 @@ -0,0 +1,23 @@ + +Unaccessible memory + +Hello, + +I'm trying to develop a OS over L4/X2 microkernel and I use Linux debian and qemu 0.13 in 64 bits mode. When I start qemu with qemu-system-x86_64 -hdc freevms.img -smp 1 -serial stdio -m 128M -k fr, my kernel boots fine. If I modify this command line with -m 384M (for example), my kernel is loaded but enter in a deadlock. I have found a bug in my code until I have tried to use the _same_ disk image under virtualbox and it works without any trouble. I runs fine on a real PC also. + +I have bissected my code and qemu stops (maybe in a deadlock) when I try to access to memory : +%MEM-I-VM_ALLOC, adding $0000000000045000 - $0000000000108FFF to VM allocator +%MEM-I-VM_ALLOC, adding $000000000010B000 - $00000000003F2FFF to VM allocator +%MEM-I-VM_ALLOC, adding $000000000040C000 - $0000000000FFFFFF to VM allocator +%MEM-I-VM_ALLOC, adding $000000000100F000 - $FFFFFEFFFFFFFFFF to VM allocator +%MEM-I-ACCMAP, accepting mapping +%MEM-I-ACCMAP, virtual $FFFF000000000000 - $FFFF000000000FFF +%MEM-I-ACCMAP, physical $000000000009E000 - $000000000009EFFF + +Note that qemu doesn't crash. It only stops. My virtual memory subsystem maps $FFFF000000000000 in physical memory ($9E000). And when I try to initialize this memory, qemu enters in deadlock. + +A disk image to reproduce this bug is available at http://www.systella.fr/~bertrand/freevms.img.bz2 + +Regards, + +JKB \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/685 b/results/classifier/deepseek-2/output/hypervisor/685 new file mode 100644 index 000000000..8208a2817 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/692570 b/results/classifier/deepseek-2/output/hypervisor/692570 new file mode 100644 index 000000000..75f599302 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/694 b/results/classifier/deepseek-2/output/hypervisor/694 new file mode 100644 index 000000000..93389f1e0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/694 @@ -0,0 +1,2 @@ + +Crash using MIPS I7200 CPU with non-nanoMIPS ELF diff --git a/results/classifier/deepseek-2/output/hypervisor/699 b/results/classifier/deepseek-2/output/hypervisor/699 new file mode 100644 index 000000000..a4fefaef5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/699 @@ -0,0 +1,2 @@ + +SGX QEMU release diff --git a/results/classifier/deepseek-2/output/hypervisor/708 b/results/classifier/deepseek-2/output/hypervisor/708 new file mode 100644 index 000000000..2f9426253 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/708 @@ -0,0 +1,11 @@ + +some TPM related files are missing in sysfs when enable passthrough TPM +Description of problem: +When enable passthrough TPM, there are some files in sysfs are missing, like description, uid file. +under the host linux, we have those file in it: +root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat description +TPM 2.0 Device +root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat uid +1 +Steps to reproduce: +after boot into system, check sysfs, there is no description and uid file in /sys/class/tpm/tpm0/device/firmware_node diff --git a/results/classifier/deepseek-2/output/hypervisor/712416 b/results/classifier/deepseek-2/output/hypervisor/712416 new file mode 100644 index 000000000..b2aa5d273 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/712416 @@ -0,0 +1,12 @@ + +kvm_intel kernel module crash with via nano vmx + +kvm module for hardware virtualisation not work properly on via nano processors. + +Tested with processor: VIA Nano processor U2250. +Processors flags (visible in /proc/cpuinfo): fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm syscall nx lm constant_tsc up rep_good pni monitor vmx est tm2 ssse3 cx16 xtpr rng rng_en ace ace_en ace2 phe phe_en lahf_lm + +With kernel 2.6.32: kvm not work and dmesg contains a lot of: +handle_exception: unexpected, vectoring info 0x8000000d intr info 0x80000b0d + +With kernel 2.6.35: all the system crash. Nothing visible in logs \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/720657 b/results/classifier/deepseek-2/output/hypervisor/720657 new file mode 100644 index 000000000..7b904f0d5 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/721793 b/results/classifier/deepseek-2/output/hypervisor/721793 new file mode 100644 index 000000000..860a45d74 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/721793 @@ -0,0 +1,23 @@ + +QEMU freezes on startup (100% CPU utilization) + +0.12.5 was the last version of QEMU that runs ok and boots any os image. + +0.13.0-0.14.0 just freeze, and the only thing I see is a black screen and both of them make it use 100% of CPU also. +Both kernels 2.6.35.11 and 2.6.37.1 with and without PAE support. + +tested commands: + +W2000: +$ qemu -m 256 -localtime -net nic,model=rtl8139 -net tap -usbdevice host:0e21:0750 /var/opt/vm/w2000.img +W2000: +$ qemu /var/opt/vm/w2000.img +OpenBSD 4.8: +$ qemu -cdrom ~/cd48.iso -boot d empty-qcow2.img + +tried to use `-M pc-0.12` selector, different audio cards (I've found it caused infinite loop on startup once) -- no luck. +tried to use recent seabios from git -- still no luck. + +attached strace log of 0.14.0. + +everything was tested on HP mini 311C with Intel Atom N270. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/722311 b/results/classifier/deepseek-2/output/hypervisor/722311 new file mode 100644 index 000000000..1b516eb8a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/722311 @@ -0,0 +1,8 @@ + +Segmentation fault if started without -enable-kvm parameter + +I start qemu (Linux) from the same USB memory stick on several computers. Up to and including qemu 0.12.5, I could use or not use qemu's "-enable-kvm" command line parameter as appropriate for the hardware, and qemu would run. In contrast, qemu 0.13.0 and 0.14.0 segfault if started without "-enable-kvm". I get a black window appearing for fractions of a second, disappearing immediately, and then the error message "Segmentation fault". + +Hardware: Pentium 4, and Core 2 Duo. +Command line: either "qemu" or "qemu -enable-kvm" (after manually loading the kvm-intel module on the Core 2 Duo). +Reproducible: always. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/728 b/results/classifier/deepseek-2/output/hypervisor/728 new file mode 100644 index 000000000..df8a39ce2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/728 @@ -0,0 +1,17 @@ + +Catch up to latest VHDX v2(=0x01) rev-7.0 specification +Additional information: +Below issues need to be addressed before or during the tackling of this issue. +- ~#727 VHDX is corrupted on expansion.~ +- #136 windows qemu-img create vpc/vhdx error due to sparse files +- #1605 On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c +- #806 Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts +- +This VHDX support applies to qemu build on any architecture, not just the windows-build. + +It is very likely, that the native hypervisor on windows WHPX will be the main hypervisor displacing haxm/vbox etc. VHDX, if it works, seems to be the virtual-disk format that is ideal +- for Linux/windows dual-boot machines, +- for clusters with Linux/windows servers sharing images from a network-storage +- for WSL2/Hyper-V + +Following a similar line of thought, NTFS/ExFat may be ideal for sharing data/images between Linux and Windows. So the storing, modification and drive attachment of VHDX files on these filesystems need to be just as well-tested as native Linux filesystems. As their driver are internal-kernel-drivers and not fuse/dokan-drivers, on both operating-systems, they are also performant. diff --git a/results/classifier/deepseek-2/output/hypervisor/73 b/results/classifier/deepseek-2/output/hypervisor/73 new file mode 100644 index 000000000..14204272b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/73 @@ -0,0 +1,2 @@ + +KVM Windows 98 sound card passthrough is not working for DOS programs.. diff --git a/results/classifier/deepseek-2/output/hypervisor/742 b/results/classifier/deepseek-2/output/hypervisor/742 new file mode 100644 index 000000000..102dfab6f --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/743 b/results/classifier/deepseek-2/output/hypervisor/743 new file mode 100644 index 000000000..2b947aa83 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/747 b/results/classifier/deepseek-2/output/hypervisor/747 new file mode 100644 index 000000000..a394c1f7c --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/748 b/results/classifier/deepseek-2/output/hypervisor/748 new file mode 100644 index 000000000..24032524c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/748 @@ -0,0 +1,2 @@ + +Enable postcopy migration for mixed Hugepage backed KVM guests and improve handling of dirty-page tracking by QEMU/KVM diff --git a/results/classifier/deepseek-2/output/hypervisor/749 b/results/classifier/deepseek-2/output/hypervisor/749 new file mode 100644 index 000000000..c77037b4d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/749 @@ -0,0 +1,2 @@ + +Enhance QEMU live patching diff --git a/results/classifier/deepseek-2/output/hypervisor/750 b/results/classifier/deepseek-2/output/hypervisor/750 new file mode 100644 index 000000000..4901c48ef --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/765 b/results/classifier/deepseek-2/output/hypervisor/765 new file mode 100644 index 000000000..863049bb7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/765 @@ -0,0 +1,66 @@ + +Issue with Docker on M1 Mac +Description of problem: +I'm trying to run a docker container using the following command: + +``` +docker run --platform=linux/amd64 --rm uphold/litecoin-core \ + -printtoconsole \ + -regtest=1 \ + -rpcallowip=172.17.0.0/16 \ + -rpcauth='foo:1e72f95158becf7170f3bac8d9224$957a46166672d61d3218c167a223ed5290389e9990cc57397d24c979b4853f8e' +``` + +It should run the docker container, instead it throws the following error: +``` +/entrypoint.sh: assuming arguments for litecoind +/entrypoint.sh: setting data directory to /home/litecoin/.litecoin +runtime: failed to create new OS thread (have 2 already; errno=22) +fatal error: newosproc + +runtime stack: +runtime.throw(0x4cb21f, 0x9) + /usr/local/go/src/runtime/panic.go:566 +0x95 +runtime.newosproc(0xc420028000, 0xc420037fc0) + /usr/local/go/src/runtime/os_linux.go:160 +0x194 +runtime.newm(0x4d6db8, 0x0) + /usr/local/go/src/runtime/proc.go:1572 +0x132 +runtime.main.func1() + /usr/local/go/src/runtime/proc.go:126 +0x36 +runtime.systemstack(0x53ae00) + /usr/local/go/src/runtime/asm_amd64.s:298 +0x79 +runtime.mstart() + /usr/local/go/src/runtime/proc.go:1079 + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/local/go/src/runtime/asm_amd64.s:252 fp=0xc420022768 sp=0xc420022760 +runtime.main() + /usr/local/go/src/runtime/proc.go:127 +0x6c fp=0xc4200227c0 sp=0xc420022768 +runtime.goexit() + /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4200227c8 sp=0xc4200227c0 +``` +Steps to reproduce: +1. Run the following in a terminal window on a Mac with an M1 chip: +``` +docker run --platform=linux/amd64 --rm uphold/litecoin-core \ + -printtoconsole \ + -regtest=1 \ + -rpcallowip=172.17.0.0/16 \ + -rpcauth='foo:1e72f95158becf7170f3bac8d9224$957a46166672d61d3218c167a223ed5290389e9990cc57397d24c979b4853f8e' +``` +Additional information: +I increased the limits using ``ulimit`` as follows: + +``` +clemens@M1-MacBook-Pro ~ % ulimit -a +-t: cpu time (seconds) unlimited +-f: file size (blocks) unlimited +-d: data seg size (kbytes) unlimited +-s: stack size (kbytes) 8176 +-c: core file size (blocks) 0 +-v: address space (kbytes) unlimited +-l: locked-in-memory size (kbytes) unlimited +-u: processes 5333 +-n: file descriptors 256 +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/771 b/results/classifier/deepseek-2/output/hypervisor/771 new file mode 100644 index 000000000..580332286 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/771 @@ -0,0 +1,15 @@ + +No interrupts are delivered to the guest after rebooting Windows 98 +Description of problem: +After Windows 98 is rebooted in QEMU, the guest freezes: the system is unresponsive to key presses and the boot splash animation halts. The guest performs fine before the reboot. + +Closer examination reveals that no hardware interrupts are delivered to the guest. BIOS Data Area variables like the keyboard buffer and the system clock are not updated. Even non-maskable interrupts fail to be delivered, as witnessed by installing an option ROM that hooks interrupt vector 2 and issuing the `nmi` command in the monitor. + +The only remedy seems to be to exit the QEMU process entirely and launch it again. +Steps to reproduce: +0. Install Windows 98 into the guest. (Since the normal installation process already involves a couple of reboots, it is possible to hit the issue already at step zero.) +1. Boot it; it may be into Safe Mode, but the protected-mode graphical environment must at least attempt to load. (I managed sometimes to reproduce the bug without the system having loaded fully.) +2. Reboot. This may be a clean reboot, or it may be a hard reboot (`system_reset` or equivalent) +3. Observe the system freeze. +Additional information: +None diff --git a/results/classifier/deepseek-2/output/hypervisor/777 b/results/classifier/deepseek-2/output/hypervisor/777 new file mode 100644 index 000000000..9c822f3f2 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/777 @@ -0,0 +1,10 @@ + +Hang on Alder Lake with multiple cores +Description of problem: +The guest silently hangs after a few seconds or minutes. No output in log, no errors in guest. +Steps to reproduce: +1. Start guest, do anything or nothing for a few minutes +Additional information: +More cores seem to make it less stable. With a single core, I haven't had a problem but at 8 cores it usually doesn't make it much past login on Windows or Linux. + +The guests are stable with 8 cores if I pin the vcpus to P cores. diff --git a/results/classifier/deepseek-2/output/hypervisor/781 b/results/classifier/deepseek-2/output/hypervisor/781 new file mode 100644 index 000000000..4432c6717 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/781 @@ -0,0 +1,2 @@ + +Assertion `addr < cache->len && 2 <= cache->len - addr' failed in address_space_stw_le_cached diff --git a/results/classifier/deepseek-2/output/hypervisor/788 b/results/classifier/deepseek-2/output/hypervisor/788 new file mode 100644 index 000000000..b08209d17 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/788697 b/results/classifier/deepseek-2/output/hypervisor/788697 new file mode 100644 index 000000000..5149a488d --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/788697 @@ -0,0 +1,4 @@ + +[PowerPC] [patch] mtmsr does not preserve high bits of MSR + +The mtmsr instruction on 64-bit PPC does not preserve the high-order 32-bits of the MSR the way it is supposed to, instead setting them to 0, which takes 64-bit code out of 64-bit mode. There is some code that does the right thing, but it brokenly only preserves these bits when the thread is not in 64-bit mode (i.e. when it doesn't matter). The attached patch unconditionally enables this code when TARGET_PPC64 is set, per the ISA spec, which fixes early boot failures trying to start FreeBSD/powerpc64 under qemu. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/789 b/results/classifier/deepseek-2/output/hypervisor/789 new file mode 100644 index 000000000..cac79b57f --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/790 b/results/classifier/deepseek-2/output/hypervisor/790 new file mode 100644 index 000000000..199453202 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/790 @@ -0,0 +1,2 @@ + +Attribute bits in stage 1/stage 2 block descriptors are not fully masked during AArch64 page table walks diff --git a/results/classifier/deepseek-2/output/hypervisor/791 b/results/classifier/deepseek-2/output/hypervisor/791 new file mode 100644 index 000000000..b1f38eed5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/791 @@ -0,0 +1,2 @@ + +unable to execute QEMU command - SGX VM using libvirtd diff --git a/results/classifier/deepseek-2/output/hypervisor/793 b/results/classifier/deepseek-2/output/hypervisor/793 new file mode 100644 index 000000000..3d9818f4e --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/793 @@ -0,0 +1,2 @@ + +Wrong pci express bus type - qemu 6.1.0-5 diff --git a/results/classifier/deepseek-2/output/hypervisor/797 b/results/classifier/deepseek-2/output/hypervisor/797 new file mode 100644 index 000000000..9f104e615 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/797 @@ -0,0 +1,10 @@ + +ARM64 hvf fails to boot Windows 11 on 6.2.0 +Description of problem: +On QEMU v6.1.0 with patches from @agraf manually applied, Windows 11 boots fine from the VHDX. Now that the patches have been mainlined, I would expect it to work the same but it gets stuck at EFI (no Windows "spinner"). +Steps to reproduce: +1. `brew install qemu` +2. Download Windows 11 VHDX from https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewARM64 +3. Run command from above. +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/809 b/results/classifier/deepseek-2/output/hypervisor/809 new file mode 100644 index 000000000..1792772b0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/809 @@ -0,0 +1,2 @@ + +ppc cpu_interrupt_exittb kvm check is inverted diff --git a/results/classifier/deepseek-2/output/hypervisor/809912 b/results/classifier/deepseek-2/output/hypervisor/809912 new file mode 100644 index 000000000..653594343 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/809912 @@ -0,0 +1,12 @@ + +qemu-kvm -m bigger 4096 aborts with 'Bad ram offset' + +When I try to start a virtual machine (x86_64 guest on a x86_64 host that has 32GB memory, using kvm_amd module, both host and guest running linux-2.6.39 kernels) with "qemu-system-x86_64 -cpu host -smp 2 -m 4096 ...", shortly after the guest kernel starts, qemu aborts with a message "Bad ram offset 11811c000". + +With e.g. "-m 3500" (or lower), the virtual machine runs fine. + +I experience this both using qemu-kvm 0.14.1 and a recent version from git +commit 525e3df73e40290e95743d4c8f8b64d8d9cbe021 +Merge: d589310 75ef849 +Author: Avi Kivity <email address hidden> +Date: Mon Jul 4 13:36:06 2011 +0300 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/816860 b/results/classifier/deepseek-2/output/hypervisor/816860 new file mode 100644 index 000000000..ef8bb5046 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/816860 @@ -0,0 +1,8 @@ + +Guest machine freezes when NFS mount goes offline + +I have a virtual KVM machine that has 2 CDROM units with ISOs mounted from a NFS mount point. When NFS server goes offline the virtual machine blocks completely instead of throwing read errors for the CDROM device. + +Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0) +KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel) +Guest: Windows 7 professional SP 1 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/857 b/results/classifier/deepseek-2/output/hypervisor/857 new file mode 100644 index 000000000..753dbfcc7 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/857 @@ -0,0 +1,13 @@ + +qemu-x86_64 uses host libraries instead of emulated system libraries +Description of problem: +I'm using Buildroot to build a cross-compiled embedded Linux system. During the build process there is a little hack to create some header file using a cross-compiled application. For this hack they use qemu to run this application. Building this embedded system for aarch64 work fine, but for x86_64 I get the following messages: + +bytecode_builtins_list_generator: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by bytecode_builtins_list_generator) + +The path of the libraries in this error message is from my host system. The embedded system uses /lib64 or /usr/lib64. It seems to me that the linker search for the libraries at first on the host system and later uses the path from the command line. So you have a mixed up of host and embedded system libraries (as you can see in the attached strace log). +Additional information: +[qemu-1.log](/uploads/f53e98b6b15cce7cbf94d14dffa39f90/qemu-1.log) diff --git a/results/classifier/deepseek-2/output/hypervisor/858 b/results/classifier/deepseek-2/output/hypervisor/858 new file mode 100644 index 000000000..5c6db65ed --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/86 b/results/classifier/deepseek-2/output/hypervisor/86 new file mode 100644 index 000000000..6982e049c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/86 @@ -0,0 +1,2 @@ + +powerpc 7450 MMU initialization broken diff --git a/results/classifier/deepseek-2/output/hypervisor/864490 b/results/classifier/deepseek-2/output/hypervisor/864490 new file mode 100644 index 000000000..fb497cda4 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/870 b/results/classifier/deepseek-2/output/hypervisor/870 new file mode 100644 index 000000000..a975260d5 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/870 @@ -0,0 +1,13 @@ + +Throws a #GP when it should throw a #SS +Description of problem: +When stacks are switched as part of a 64-bit mode privilege-level change (resulting from an interrupt), IA-32e mode loads only an inner-level RSP from the TSS. If the value of rsp from tss is a non-canonical form. It will trigger #SS. But when I test it in qemu it throws #GP instead of #SS +Steps to reproduce: +In order to confirm that it is the #SS triggered by the non-canonical address, We can verify on a real machine. +1. Set the value of the current core's `TSS.IST7` to the the non-canonical address. +2. Set the `ist` field of the interrupt 4 (Overflow Exception) descriptor to 7. +3. Execute the `INT 4` instruction in Ring 3 and it will be taken over by the #SS handler. + +Repeat the above steps in qemu this exception will be taken over by #GP +Additional information: + diff --git a/results/classifier/deepseek-2/output/hypervisor/871 b/results/classifier/deepseek-2/output/hypervisor/871 new file mode 100644 index 000000000..78aa0c8b8 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/871 @@ -0,0 +1,15 @@ + +qemu-x86_64 don't support unshare(CLONE_NEWUSER) +Description of problem: +Why qemu-x86_64 call unshare(CLONE_NEWUSER) fail? +``` + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ qemu-x86_64 /bin/unshare --user /bin/bash + unshare: unshare failed: Invalid argument + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ /bin/unshare --user /bin/bash + nobody@ubuntu:~/Desktop/afl/AFLplusplus$ +``` +Steps to reproduce: +1.execute `qemu-x86_64 /bin/unshare --user /bin/bash` ,it will fail <br/> +2.execute `/bin/unshare --user /bin/bash` ,it will ok + +How i fix that? diff --git a/results/classifier/deepseek-2/output/hypervisor/883 b/results/classifier/deepseek-2/output/hypervisor/883 new file mode 100644 index 000000000..a4298fc46 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/883 @@ -0,0 +1,28 @@ + +DRBG: could not allocate CTR cipher TFM handle: ctr(aes) +Description of problem: + +Steps to reproduce: +1. Install Debian in Qemu using the command: +``` +REM example to create disk +REM qemu-img create -f qcow2 debian-qcow2.img 32G + +qemu-system-x86_64.exe -hda debian-qcow2.img -cdrom debian-11.2.0-amd64-netinst.iso -boot d -m 8G -accel hax +``` + +2. Fight with installer and partitions to finally get this: + + +3. System boots and shows a bunch of FAILED messages with crypto error: + + + + +I am new at using Qemu so may need pointers to provide more information. + +The system seems to be working to some degree. + +Color me impressed!!! +Additional information: +Related: #880 diff --git a/results/classifier/deepseek-2/output/hypervisor/886 b/results/classifier/deepseek-2/output/hypervisor/886 new file mode 100644 index 000000000..1afae55f3 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/886 @@ -0,0 +1,17 @@ + +OpenIndiana panics when using -accel hvf +Description of problem: +OpenIndiana panics on boot. + +``` +Loading unix... +Loading /platform/i86pc/amd64/boot_archive... +Loading /platform/i86pc/amd64/boot_archive.hash... +Booting... +OpenIndiana Hipster 2021.10 Version illumos-79a6379db8 64-bit + +panic[cpu0]/thread=fffffffffbc49060: +``` +Steps to reproduce: +1. Run given command +2. Wait diff --git a/results/classifier/deepseek-2/output/hypervisor/887 b/results/classifier/deepseek-2/output/hypervisor/887 new file mode 100644 index 000000000..fad729d74 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/887 @@ -0,0 +1,2 @@ + +OSX Sorbet Leopard 10.5.9 on QEMU ? diff --git a/results/classifier/deepseek-2/output/hypervisor/888 b/results/classifier/deepseek-2/output/hypervisor/888 new file mode 100644 index 000000000..cd5db783b --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/891625 b/results/classifier/deepseek-2/output/hypervisor/891625 new file mode 100644 index 000000000..ee9957193 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/891625 @@ -0,0 +1,5 @@ + +[qemu-kvm] add vhost-net to kvm group udev rules 65-kvm.rules + +Please consider authorizing the kvm group to access vhost-net device, similar to the kvm device. +Thanks! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/893208 b/results/classifier/deepseek-2/output/hypervisor/893208 new file mode 100644 index 000000000..84c0421ad --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/893208 @@ -0,0 +1,4 @@ + +qemu on ARM hosts can't boot i386 image + +If you apply some workarounds for bug 870990, bug 883133 and bug 883136 QEMU still cannot boot the i386 debian_squeeze_i386_standard.qcow2 image from http://people.debian.org/~aurel32/qemu/i386/ -- grub starts to boot but something causes the system to reset just before display of the blue-background grub menu, so we go round in a loop forever. This image boots OK on i386 hosted qemu so this indicates some kind of ARM-host specific bug. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/894 b/results/classifier/deepseek-2/output/hypervisor/894 new file mode 100644 index 000000000..2c85e9d3b --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/894 @@ -0,0 +1,32 @@ + +target/riscv64 qemu-iotests 040 failed +Description of problem: +I cross-compiled a riscv64 QEMU flavor based on the most updated code, then make check. Some qemu-iotests failed, 040 041 127 256 267. I mainly focused on test 040 and tried to find out what happened. +Steps to reproduce: +1. change directory to QEMU source tree root +2. ./configure --prefix=~/temp --target-list=riscv64-softmmu +3. make +4. cd build/tests/qemu-iotests/ +5. ./check -qcow2 040 + +Then a lot of error messages(please see attachment). The following log might hint the root cause I thought: +``` ++ Command: /home/qemu/qemu/build/tests/qemu-iotests/../../qemu-system-riscv64 -display none -vga none -chardev socket,id=mon,path=/tmp/tmpwhnx3jq0/qemu-28363-monitor.sock -mon chardev=mon,mode=control -qtest unix:path=/tmp/tmpwhnx3jq0/qemu-28363-qtest.sock -accel qtest -nodefaults -display none -accel qtest -drive if=none,id=drive0,file=/home/qemu/qemu/build/tests/qemu-iotests/scratch/test.img,format=qcow2,cache=writeback,aio=threads,node-name=top,backing.node-name=mid,backing.backing.node-name=base -device virtio-scsi -device scsi-hd,id=scsi0,drive=drive0 ++ Output: [I 1646574338.669217] OPENED ++qemu-system-riscv64: -device virtio-scsi: No 'PCI' bus found for device 'virtio-scsi-pci' +``` +The command had no '-machine' argument. For riscv64 target, 'spike' will be the default machine. Maybe 'spike' have no PCI bus? Then I tried to change it to 'virt' machine but failed, nothing new happen. +``` +QEMU_DEFAULT_MACHINE=virt ./check -qcow2 040 +``` +``` +QEMU_OPTIONS="-machine virt" ./check -qcow2 040 +``` +Last, I modified [testenv.py](https://gitlab.com/qemu-project/qemu/-/blob/master/tests/qemu-iotests/testenv.py#L239) and added one line in machine-map, all tests passed! +``` +('riscv64', 'virt'), +``` + +Is there any way to easy the issue or do I miss something? Thank you! +Additional information: +[zlog.riscv.xz](/uploads/cbbad7c5c256d2b49d220aa6425e2b17/zlog.riscv.xz) diff --git a/results/classifier/deepseek-2/output/hypervisor/897 b/results/classifier/deepseek-2/output/hypervisor/897 new file mode 100644 index 000000000..7e14876e0 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/897 @@ -0,0 +1,2 @@ + +Warning with "qemu-s390x -cpu max" diff --git a/results/classifier/deepseek-2/output/hypervisor/899 b/results/classifier/deepseek-2/output/hypervisor/899 new file mode 100644 index 000000000..6b9bddafc --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/900 b/results/classifier/deepseek-2/output/hypervisor/900 new file mode 100644 index 000000000..f99694228 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/900 @@ -0,0 +1,2 @@ + +how to install gemu guest agent without configure script ? diff --git a/results/classifier/deepseek-2/output/hypervisor/906221 b/results/classifier/deepseek-2/output/hypervisor/906221 new file mode 100644 index 000000000..94c676a37 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/906221 @@ -0,0 +1,33 @@ + +USBDEVFS_CLEAR_HALT stall with USB-CDROM qemu-1.0 + +When connecting a USB DVD/CDROM drive to the linux host, it works fine and I can mount the inserted DVD properly and work with it. After unmounting the DVD and routing the USB drive to the linux guest (same kernel version), both host and guest become unresponsive and on the QEMU console I get the QEMU console flodded with the message: +USBDEVFS_CLEAR_HALT: Connection timed out +again and again, approx. each 10-20 seconds. + +When I unplug the device from the host, the message +USBDEVFS_CLEAR_HALT: No such device +comes up in one block at least 100 times (my scrollback history of the display is limited, so I cannot say how often it actually appreared) + +On the guest side linux, I see the following dmesg after having it routed from the host to the guest: +[ 160.292231] usb 1-2.1: new full speed USB device using uhci_hcd and address 5 +[ 160.475762] usb 1-2.1: configuration #1 chosen from 1 choice +[ 160.478553] scsi3 : SCSI emulation for USB Mass Storage devices +[ 160.479689] usb-storage: device found at 5 +[ 160.480121] usb-storage: waiting for device to settle before scanning +[ 165.494016] scsi 3:0:0:0: CD-ROM slimtype eTDU108 1 SL03 PQ: 0 ANSI: 0 + +then, the guest stalls and on the host side the USBDEVFS_CLEAR_HALT appears until I unplug the hardware from the host - pay also attention on the stalled dmesg timestamp! The "real" timegap between the last line above and the first line below is more than 20 seconds! + +[ 165.645735] usb 1-2.1: USB disconnect, address 5 +[ 165.663770] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda pop-up +[ 165.664416] sr 3:0:0:0: Attached scsi CD-ROM sr0 +[ 165.664623] sr 3:0:0:0: Attached scsi generic sg1 type 5 +[ 165.665565] usb-storage: device scan complete + +The drive used is a self-powered LITEON External Slim DVD-ROM Drive (Model number eTDU108-02 1) +The power is not a problem, because the drive works fine on the host directly. + +Best regards, + +Erik \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/917645 b/results/classifier/deepseek-2/output/hypervisor/917645 new file mode 100644 index 000000000..f0c4dd1d6 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/917645 @@ -0,0 +1,6 @@ + +[Feature request] ia64-softmmu wanted + +Qemu is missing support for full system emulation of the Itanium architecture, which is one of the main non-x86 server architectures today (despite the alleged decline in popularity). It would be really nice if someone had interest in adding full ia64 support to Qemu. Many OS projects could then use Qemu as the universal machine emulator for development and testing. + +Note that there is an open source Ski simulator which can emulate an ia64 CPU, memory and a couple of Ski-specific devices, but the project seems inactive and the simulated machine is too simplified (no real devices, no real firmware). Moreover, it'd be better to have one tool such as Qemu for all architectures of interest rather than one per each architecture. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/hypervisor/918 b/results/classifier/deepseek-2/output/hypervisor/918 new file mode 100644 index 000000000..0b159b798 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/918 @@ -0,0 +1,2 @@ + +TILE Cpu Host & Emulator support? diff --git a/results/classifier/deepseek-2/output/hypervisor/920 b/results/classifier/deepseek-2/output/hypervisor/920 new file mode 100644 index 000000000..bb9e4d092 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/920 @@ -0,0 +1,13 @@ + +Aarch64 QEMU+KVM+OVMF RAM Bug +Description of problem: +OVMF EDK2 does not recognize any amount of RAM. It always detects as 0 MB and causes operating systems to crash. +Steps to reproduce: +1. +2. +3. +Additional information: +There was a problem with the Redmi Note 10S device via Termux. +  + + ovmf diff --git a/results/classifier/deepseek-2/output/hypervisor/934 b/results/classifier/deepseek-2/output/hypervisor/934 new file mode 100644 index 000000000..92b98d36b --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/953 b/results/classifier/deepseek-2/output/hypervisor/953 new file mode 100644 index 000000000..fef559a8c --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/953 @@ -0,0 +1,2 @@ + +qemu-system-aarch64 asserts trying to execute STXP on hosts without HAVE_CMPXCHG128 diff --git a/results/classifier/deepseek-2/output/hypervisor/96 b/results/classifier/deepseek-2/output/hypervisor/96 new file mode 100644 index 000000000..430a6eb41 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/96 @@ -0,0 +1,2 @@ + +qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend diff --git a/results/classifier/deepseek-2/output/hypervisor/963 b/results/classifier/deepseek-2/output/hypervisor/963 new file mode 100644 index 000000000..7ca8f99ad --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/963 @@ -0,0 +1,2 @@ + +qemu-7.0.0-rc2/migration/ram.c:1292: possible wrong operator ? diff --git a/results/classifier/deepseek-2/output/hypervisor/968 b/results/classifier/deepseek-2/output/hypervisor/968 new file mode 100644 index 000000000..5b787493a --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/968 @@ -0,0 +1,96 @@ + +QEMU guest agent fails to install if COM+ Application: QEMU Guest Agent VSS Provider not properly uninstalled +Description of problem: +QEMU guest agent fails to install if COM+ Application: QEMU Guest Agent VSS Provider not properly uninstalled +Steps to reproduce: +1. Install QEMU guest agent +2. Uninstall QEMU guest agent (in rare cases it didn't uninstall the COM+ component) +3. Install QEMU guest agent and get error: `Product: QEMU guest agent -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action RegisterCom, location: cmd.exe, command: /c "C:\Program Files\Qemu-ga\qemu-ga.exe" -s vss-install` +Additional information: +1. **Qemu GA is already uninstalled:** + +``` +gwmi Win32_Product + + +IdentifyingNumber : {EE3877E4-07B0-41F2-ADB8-B45133DDCE37} +Name : Spice Agent 0.10.0-5 (64-bit) +Vendor : Red Hat, Inc. +Version : 0.10.5 +Caption : Spice Agent 0.10.0-5 (64-bit) + +IdentifyingNumber : {4C49C419-DE39-421B-B0F8-5F0DE1486869} +Name : Virtio-win-driver-installer +Vendor : Red Hat, Inc. +Version : 0.1.189 +Caption : Virtio-win-driver-installer + +IdentifyingNumber : {85F4CBCB-9BBC-4B50-A7D8-E1106771498D} +Name : Orca +Vendor : Microsoft Corporation +Version : 3.1.5299.0000 +Caption : Orca + +IdentifyingNumber : {89F4137D-6C26-4A84-BDB8-2E5A4BB71E00} +Name : Microsoft Silverlight +Vendor : Microsoft Corporation +Version : 5.1.50918.0 +Caption : Microsoft Silverlight + +IdentifyingNumber : {AB392F9F-0C0C-4098-B5BA-B1E84E62D6CE} +Name : Icinga 2 +Vendor : Icinga GmbH +Version : 2.11.0 +Caption : Icinga 2 +``` + +2. **Extract files from installer and run `qemu-ga.exe -s vss-install`** + +It fails with: `QGA VSS Provider is already installed. (Error: 80004004) Vorgang abgebrochen` + +3. **Uninstall COM+ component: `qemu-ga.exe -s vss-uninstall`** + +`Removing COM+ Application: QEMU Guest Agent VSS Provider` + +4. **Now you can install GA** + +``` +gwmi Win32_Product + + +IdentifyingNumber : {EE3877E4-07B0-41F2-ADB8-B45133DDCE37} +Name : Spice Agent 0.10.0-5 (64-bit) +Vendor : Red Hat, Inc. +Version : 0.10.5 +Caption : Spice Agent 0.10.0-5 (64-bit) + +IdentifyingNumber : {4C49C419-DE39-421B-B0F8-5F0DE1486869} +Name : Virtio-win-driver-installer +Vendor : Red Hat, Inc. +Version : 0.1.189 +Caption : Virtio-win-driver-installer + +IdentifyingNumber : {85F4CBCB-9BBC-4B50-A7D8-E1106771498D} +Name : Orca +Vendor : Microsoft Corporation +Version : 3.1.5299.0000 +Caption : Orca + +IdentifyingNumber : {99AD6A3C-F854-4E6E-865F-11D4A5E46172} +Name : QEMU guest agent +Vendor : RedHat +Version : 101.1.0 +Caption : QEMU guest agent + +IdentifyingNumber : {89F4137D-6C26-4A84-BDB8-2E5A4BB71E00} +Name : Microsoft Silverlight +Vendor : Microsoft Corporation +Version : 5.1.50918.0 +Caption : Microsoft Silverlight + +IdentifyingNumber : {AB392F9F-0C0C-4098-B5BA-B1E84E62D6CE} +Name : Icinga 2 +Vendor : Icinga GmbH +Version : 2.11.0 +Caption : Icinga 2 +``` diff --git a/results/classifier/deepseek-2/output/hypervisor/970 b/results/classifier/deepseek-2/output/hypervisor/970 new file mode 100644 index 000000000..f0c9ae355 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/970 @@ -0,0 +1,34 @@ + +ARM SCTLR allows writes to "write ignore" bits +Description of problem: +The firmware I have executed in qemu sets up pagetables and then enables the MMU. +A few instructions later, a prefetch abort was occurring. After debugging it turned out the problem was because get_phys_addr_v5 was being used to walk the pagetable instead of get_phys_addr_v6. +qemu has this code: +```c +regime_sctlr(env, mmu_idx) & SCTLR_XP +// where SCTLR_XP is commented as +#define SCTLR_XP (1U << 23) /* up to v6; v7 onward RAO */ +``` +Somewhat interestingly, A5 has a lot of bits marked as `/WI`: https://developer.arm.com/documentation/ddi0433/c/system-control/register-descriptions/system-control-register + +A9 has less, but still a few which qemu is not handling: https://developer.arm.com/documentation/ddi0388/e/the-system-control-coprocessors/summary-of-system-control-coprocessor-registers/system-control-register +I've made this hacky patch to fix it for myself: +```diff +diff --git a/qemu/target/arm/helper.c b/qemu/target/arm/helper.c +index 60c9db9e..d8fd5a7d 100644 +--- a/qemu/target/arm/helper.c ++++ b/qemu/target/arm/helper.c +@@ -4306,6 +4306,11 @@ static void sctlr_write(CPUARMState *env, const ARMCPRegInfo *ri, + { + ARMCPU *cpu = env_archcpu(env); + ++ // for cortex-a5 specifically ++ value |= (0b11 << 22) | (1 << 18) | (1 << 16) | (0b1111 << 3); ++ value &= ~((1 << 31) | (0b11 << 26) | (1 << 24) | (0b111 << 19) | ++ (1 << 17) | (0b11 << 14) | (0b111 << 7)); ++ + if (raw_read(env, ri) == value) { + /* Skip the TLB flush if nothing actually changed; Linux likes + * to do a lot of pointless SCTLR writes. +``` +I think the real fix would allow expressing the ones/zeros mask as part of `ARMCPU` per-arch. diff --git a/results/classifier/deepseek-2/output/hypervisor/974 b/results/classifier/deepseek-2/output/hypervisor/974 new file mode 100644 index 000000000..d4b1a9a17 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/974 @@ -0,0 +1,4 @@ + +Enable virtio-9pfs on windows hosts +Additional information: +attn: @schoenebeck diff --git a/results/classifier/deepseek-2/output/hypervisor/974958 b/results/classifier/deepseek-2/output/hypervisor/974958 new file mode 100644 index 000000000..b8366e672 --- /dev/null +++ b/results/classifier/deepseek-2/output/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/deepseek-2/output/hypervisor/995 b/results/classifier/deepseek-2/output/hypervisor/995 new file mode 100644 index 000000000..a09f8c122 --- /dev/null +++ b/results/classifier/deepseek-2/output/hypervisor/995 @@ -0,0 +1,12 @@ + +Segfault when saving VM snapshot via QEMU monitor on MIPS and MIPSEL +Description of problem: +When entering the QEMU monitor using Ctrl-A then C, and running the savevm QEMU command, the emulator hangs for a while and then exits with a segfault. This occurs on MIPS and MIPSEL system emulators using the same command line arguments. ARM32, aarch64 and x86_64 emulators don't seem to have this problem. I haven't tested it on any other architectures as I don't have kernel or drive images for them. `qemu-img` seems to work fine with the QCOW2 images used for this test, I was able to create and load offline snapshots from them. The images were created from raw EXT2 filesystem images produced by Buildroot, using `qemu-img convert`. +Steps to reproduce: +1. Start the QEMU system emulator for MIPS/MIPSEL with the given command line. +2. Enter the QEMU monitor with Ctrl-A, C. +3. Run `savevm <vm name>`. +Additional information: +I tried logging what QEMU was doing with the `-D ./log.txt` command line option, but the produced log file was empty. + +If you need me to send you the kernel image files and QCOW2 images used, I would be happy to do so. |