restructure results

author: Christian Krinitsin <mail@krinitsin.com> 2025-07-03 19:39:53 +0200
committer: Christian Krinitsin <mail@krinitsin.com> 2025-07-03 19:39:53 +0200
commit: dee4dcba78baf712cab403d47d9db319ab7f95d6 (patch)
tree: 418478faf06786701a56268672f73d6b0b4eb239 /results/classifier/deepseek-1/output/hypervisor
parent: 4d9e26c0333abd39bdbd039dcdb30ed429c475ba (diff)
download: emulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.tar.gz
emulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.zip
44 files changed, 0 insertions, 2331 deletions
diff --git a/results/classifier/deepseek-1/output/hypervisor/1078892 b/results/classifier/deepseek-1/output/hypervisor/1078892
deleted file mode 100644
index 0b773c55..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1078892
+++ /dev/null
@@ -1,12 +0,0 @@
-
-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.
-
-Triaging old bug tickets ... can you still reproduce this issue with the
-latest version of QEMU (version 2.9)?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1217339 b/results/classifier/deepseek-1/output/hypervisor/1217339
deleted file mode 100644
index b8ee3632..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1217339
+++ /dev/null
@@ -1,71 +0,0 @@
-
-SIGQUIT to send ACPI-shutdown to Guest
-
-When qemu receives SIGQUIT, it should first try to run system_powerdown (giving the guest an ACPI signal to begin the shutdown process), before ending the whole qemu process.
-
-At this point there is no way to do a graceful shutdown if you do not have access to the monitor and you do not use any wrapper like libvirt.
-
-If, for some reason SIGQUIT would not be accepted as the signal, take any free to use signal, like SIGUSR1. There should be a way to get ACPI shutdown sent to the guest.
-
-On 08/27/13 14:29, Lasse wrote:
-> Public bug reported:
-> 
-> When qemu receives SIGQUIT, it should first try to run system_powerdown
-> (giving the guest an ACPI signal to begin the shutdown process), before
-> ending the whole qemu process.
-
-I strongly disagree. SIGQUIT is an interactive debugging signal. It is
-there so that the user running qemu can trigger a core dump from the
-terminal, when he/she notices a problem.
-
-http://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html#index-SIGQUIT-2854
-
-> At this point there is no way to do a graceful shutdown if you do not
-> have access to the monitor and you do not use any wrapper like libvirt.
-> 
-> If, for some reason SIGQUIT would not be accepted as the signal, take
-> any free to use signal, like SIGUSR1. There should be a way to get ACPI
-> shutdown sent to the guest.
-
-What's wrong with SIGINT / SIGTERM? Those signals are there to request a
-clean shutdown (from the terminal and from an unrelated process,
-respectively).
-
-As far as I can see, both SIGINT and SIGTERM end up in
-qemu_system_shutdown_request() on POSIX:
-
-termsig_handler() [os-posix.c]
-  qemu_system_killed() [vl.c]
-    qemu_system_shutdown_request()
-
-Laszlo
-
-
-
-Here is a short patch making Qemu to properly power off the guest when receiving a SIGHUP signal.
-
-I do not think that the way SIGTERM is handled should be modified as it is needed to ask Qemu to forcefully close an unresponsive guest without having to SIGKILL Qemu itself. Regarding SIGINT this is mostly a matter of user expectation (Ctrl-C result), in doubt I keep the original behavior.
-
-On the other side, SIGHUP has a much flexible definition making it a good candidate for the job.
-
-IMHO I think such feature is really useful as it allows to cleanly close all running VM without having to involve Qemu monitor in any way:
-
-1. Send SIGHUP to all Qemu processes so the guests power off cleanly.
-2. After a few time send SIGTERM to the remaining Qemu processes to forcefully close stuck guests.
-3. After a few time send SIGKILL to the remaining Qemu processes to forcefully close stuck Qemu hypervisor processes.
-
-I find this more convenient than having to fiddle with Qemu monitor to implement step 1 as it must currently be done.
-
-Please do not add patches to the bugtracker. Post them to the mailing list instead. See http://wiki.qemu-project.org/Contribute/SubmitAPatch for information how to contribute a patch.
-
-(and I am also not sure whether SIGHUP is the right signal for this job - the original request was also about SIGQUIT instead)
-
-Sorry Thomas, I was not aware of this page. I checked the CODING_STYLE file present in Qemu source before submitting this, maybe it could be useful to include this URL there.
-
-Meanwhile, for reference the discussion continues there:
-https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03039.html
-
-Regards.
-
-The discussion noted in comment#4 petered out in March 2017. Closing this ticket as "Invalid" (only because LP does not let me use the "Won't Fix" resolution -- the report / feature request may very well have had merit, but apparently a good enough design could not be found).
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1438572 b/results/classifier/deepseek-1/output/hypervisor/1438572
deleted file mode 100644
index 762eaace..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1438572
+++ /dev/null
@@ -1,22 +0,0 @@
-
-kvm does not support KVM_CAP_USER_MEMORY Please upgrade to at least kernel 2.6.29 or recent kvm-kmod (see http://sourceforge.net/projects/kvm)
-
-We have a machine which is having QEMU+KVM on below configuration of linux
-uname -a
-Linux cairotrior 2.6.18-308.13.1.el5 #1 SMP Thu Jul 26 05:45:09 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
-cat /etc/issue
-Red Hat Enterprise Linux Server release 5.8 (Tikanga)
-Kernel \r on an \m
-
-
-But in another setup, we are trying on a different machine having RHEL 5.9 having higher kernel version but it still gives below error
-kvm does not support KVM_CAP_USER_MEMORY Please upgrade to at least kernel 2.6.29 or recent kvm-kmod (see http://sourceforge.net/projects/kvm).
-failed to initialize KVM: Invalid argument No accelerator found!
-
-
-I don’t know if the qemu version have compatibility issues with redhat 5.9 version –  need someone to check if the qemu can run on redhat 5.9 64 bit or not ?
-
-Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
-
-This error has never existed in QEMU, only in the old qemu-kvm fork which has been obsolete for about 5 years.  I'm closing this ticket.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1470720 b/results/classifier/deepseek-1/output/hypervisor/1470720
deleted file mode 100644
index c48e7976..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1470720
+++ /dev/null
@@ -1,54 +0,0 @@
-
-high IRQ-TLB generates network interruptions
-
- we are having a problem in our hosts, all the vm running on them suddenly, and for some seconds, lost network connectivity.
-
-the root cause appears to be the increase of irb-tlb from low values (less than 20) to more than >100k, that spike only last for some seconds then everything goes back to normal
-
-i've upload an screenshot of collectd for one hypervisor here
-http://zumbi.com.ar/tmp/irq-tlb.png
-
-
-we have hosts running precise (qemu 1.5, ovs 2.0.2, libvirt 1.2.2 and kernel 3.13) where the issue is frequent. also we have an small % of our fleet running trusty (qemu 2.0.0 ovs 2.0.2 libvirt 1.2.2 and kernel 3.16) where the problem seemed to be nonexistent until today
-
-issue seems to be isolated to < 10% of our hypervisors, some hypervisors had this problem every few days, others only once or twice. our vm are a black box to us we don't know what users run on them, but mostly cpu and network bound workload.
-most of our guests run centos 6.5 (kernel 2.6.32)
-
-vm are bridged to a linuxbridge then veth wired to an ovs switch (neutron openvswitch agent setup)
-
-
-
-maybe first part is not clear, here it goes again
-
- this happens on some hypervisors at random times, not all hypervisors at the same time, and affects all vm on the hypervisor
-
-overcommit ratio on latest server i had the problem is 3.6 (3.6 vcpu for each cpu), would that be part of the problem?  i see other servers that never had the problem with over commit ratios as high as 4.1 
-
-Seeing the same here, also happens on overbooked hypervisors.
-
-Just one or two hosts have this behaviour.
-
-We are using:
-qemu-kvm                             2.0.0+dfsg-2ubuntu1.25
-libvirt-bin                          1.2.9
-kernel  3.13.0-92-generic
-
-We are using contrail as a SDN.
-
-It looks like it started after upgrading a bunch of packages including kernel (we came from 3.13.0-83-generic)
-
-
-Disabling huge pages seem to help.
-Strangely this should theoretically increase the issue but it so far we have not seen issues after disabling THP.
-(have not seen high load spikes in a week but this might also be holiday related)
-
-So other people can try it out:
-echo never >/sys/kernel/mm/transparent_hugepage/defrag
-echo never > /sys/kernel/mm/transparent_hugepage/enabled
-
-
-
-Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1529187 b/results/classifier/deepseek-1/output/hypervisor/1529187
deleted file mode 100644
index eeb9aa21..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1529187
+++ /dev/null
@@ -1,44 +0,0 @@
-
-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:
- ----------------------
-
-
-
-
-You've somehow managed to not load the vfio_iommu_type1 module.  The vfio module will request it when loading, if the module is not available when loading, such as from an initramfs that does not include the full set of vfio modules, it will need to be loaded later manually.
-
-You're right. After I manually load vfio_iommu_type1, the error is gone.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1590796 b/results/classifier/deepseek-1/output/hypervisor/1590796
deleted file mode 100644
index a2098d54..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1590796
+++ /dev/null
@@ -1,48 +0,0 @@
-
-2.6.0 Windows 7 install hangs on splash screen, works ok with 2.5.1
-
-Hi maintainers,
-
-I have tried to install Windows 7 SP1 from the ISO. The install process hangs on the windows 4 color logo with qemu 2.6.0, it works and installs fine with 2.5.1.
-
-This is the script I used with 2.5.1 and it works perfectly fine:
-
-#!/bin/sh
-exec qemu-system-x86_64 \
-        -enable-kvm \
-        -uuid 0ec801a0-d215-464b-a658-8f43a24cb62e \
-        -machine q35 \
-        -cpu host \
-        -smp cores=2,threads=2 \
-        -drive file=disk/ovmfcode.flash,format=raw,readonly,if=pflash \
-        -drive file=disk/ovmfvars.flash,format=raw,if=pflash \
-        -drive file=disk/windows7.img,discard=unmap,detect-zeroes=unmap,cache=unsafe,if=virtio \
-        -drive file=ISO/windows7.iso,media=cdrom \
-        -drive file=ISO/virtiowin.iso,media=cdrom \
-        -netdev tap,id=nic-0,ifname=tap0,vhost=on,script=no,downscript=no \
-        -net nic,macaddr=52:54:00:01:00:01,netdev=nic-0,model=virtio \
-        -m 4G \
-        -vga qxl \
-        -soundhw ac97 \
-        -usbdevice tablet \
-        -rtc clock=host,base=utc \
-        -name "Windows 7" \
-        -monitor telnet:127.0.0.1:2001,server,nowait \
-        -daemonize
-
-The same hangs on the splash screen with 2.6.0
-
-Even the following simple script behaves the same and hangs at splash screen with 2.6.0:
-
-#!/bin/sh
-exec qemu-system-x86_64 \
-        -drive file=disk/windows7.img,if=ide \
-        -drive file=ISO/windows7.iso,media=cdrom \
-        -name "Windows 7" \
-        $@
-
-The ISO is Windows 7 Ultimate english version, Service Pack 1. 
-I reproduced the same behaviour on Gentoo and Arch, with the Qemu versions provided on both distributions.
-
-Cheers
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1629282 b/results/classifier/deepseek-1/output/hypervisor/1629282
deleted file mode 100644
index 46845c5b..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1629282
+++ /dev/null
@@ -1,65 +0,0 @@
-
-QEMU (still) hangs on Windows 7 install
-
-I'm trying to install Windows 7 as guest, but the machine still hangs (more precisely, the windows icon keeps flashing, but never goes past this stage).
-
-I think this is a different bug from https://bugs.launchpad.net/qemu/+bug/1581936.
-
-Specifically, its happens when the OVMF BIOS is used, and I can't find any workaround (in the above bug, by changing the display, the installation doesn't hang).
-
-The most minimal commandline that reproduces the issue is (generic format):
-
-$QEMU_BINARY \
-  -drive if=pflash,format=raw,readonly,file=$QEMU_BIOS \
-  -drive if=pflash,format=raw,file=$QEMU_BIOS_TMP \
-  -enable-kvm \
-  -m $QEMU_MEMORY \
-  -display std \
-  -cpu host,kvm=off -smp 4,sockets=1,cores=4 \
-  -cdrom $QEMU_WINDOWS_7_CD \
-;
-
-I'm using `OVMF_15214.fd` as BIOS.
-
-I'll assume "OVMF_15214.fd" is from <http://www.tianocore.org/ovmf/>. It's an ancient build of OVMF (older than two and half years). The binary packaged in that ZIP file isn't even a split one, it's a unified binary that is unsuitable for the command line that you've given above.
-
-Please either grab the most recent OVMF build from your distribution, or a bleeding edge build from <https://www.kraxel.org/repos/> (recommended). Then create a copy of the varstore template, to be used as the VM's own private variable store. Also, fix the "-display std" command line option, as in "-vga std". It will just work then.
-
-Below I'll specify the commands that I just re-tested. Note that I'm also renaming the QEMU_BIOS and QEMU_BIOS_TMP variables (whose names are quite inappropriate) to FIRMWARE_BINARY and VARIABLE_STORE.
-
-    # this binary corresponds to upstream git cc9a366d3b16,
-    # dated "Thu Sep 29 00:34:20 2016 +0100"
-    QEMU_BINARY=/opt/qemu-installed/bin/qemu-system-x86_64
-
-    # these files are from package
-    # "edk2.git-ovmf-x64-0-20160929.b2144.g84bc72f.noarch", installed
-    # from kraxel.org
-    FIRMWARE_BINARY=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
-    VARIABLE_STORE_TEMPLATE=/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd
-    VARIABLE_STORE=/tmp/guest1-vars.fd
-
-    # Windows 7 installer disk
-    QEMU_WINDOWS_7_CD=en_windows_7_enterprise_n_with_sp1_x64_dvd_u_677704.iso
-
-    # other settings
-    QEMU_MEMORY=2048
-
-    # create empty variable store from pristine template if the varstore doesn't
-    # exist yet, or has been lost for some reason
-    if ! [ -e "$VARIABLE_STORE" ]; then
-      cp -v -- "$VARIABLE_STORE_TEMPLATE" "$VARIABLE_STORE"
-    fi
-
-    $QEMU_BINARY \
-        -drive if=pflash,format=raw,readonly,file="$FIRMWARE_BINARY" \
-        -drive if=pflash,format=raw,file="$VARIABLE_STORE" \
-        -enable-kvm \
-        -m $QEMU_MEMORY \
-        -vga std \
-        -cpu host,kvm=off -smp 4,sockets=1,cores=4 \
-        -cdrom $QEMU_WINDOWS_7_CD
-
-
-
-Thanks! Using the OVMF provided with the Ubuntu 16.04 packages solved the issue.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1689245 b/results/classifier/deepseek-1/output/hypervisor/1689245
deleted file mode 100644
index 987af75f..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1689245
+++ /dev/null
@@ -1,23 +0,0 @@
-
-qcow2 image converted from Photon OS can't be started
-
-Steps to reproduce the issue:
-1. Download the ovf from this place:
-https://bintray.com/vmware/photon/download_file?file_path=photon-custom-hw10-1.0-62c543d.ova
-2. Extract vmdk from ova file.
-3. Convert from vmdk fromat to qcow2 via qeum-img
-4. Launch the qcow2 image. The VM is started. But there is no any output. CPU usage is 100%
-
-I try this steps and meet the similar issue:
-1. Deploy a VM in ESXi from https://bintray.com/vmware/photon/download_file?file_path=photon-custom-hw10-1.0-62c543d.ova
-2. Copy vmdk and flat.vmdk file
-3. Convert from vmdk format to raw via qeum-img(qemu-img convert -f vmdk -O raw Photon.vmdk Photon.raw)
-4. Launch the qcow2 image. The VM is started. And the splash screen is showed. But then there is no any output.
-
-The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
-If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
-
-Additional question if this is still relevant: How did you run QEMU here, i.e. which command line parameters did you use?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1705717 b/results/classifier/deepseek-1/output/hypervisor/1705717
deleted file mode 100644
index 7acb0523..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1705717
+++ /dev/null
@@ -1,64 +0,0 @@
-
-Live migration fails with 'host' cpu when KVM is inserted with nested=1
-
-Qemu v2.9.0
-Linux kernel 4.9.34
-
-Live migration(pre-copy) being done from one physical host to another:
-
-Source Qemu:
-sudo qemu-system-x86_64 -drive file=${IMAGE_DIR}/${IMAGE_NAME},if=virtio -m 2048 -smp 1 -net nic,model=virtio,macaddr=${MAC} -net tap,ifname=qtap0,script=no,downscript=no -vnc :1 --enable-kvm -cpu kvm64 -qmp tcp:*:4242,server,nowait
-
-And KVM is inserted with nested=1 on both source and destination machine.
-
-Migration fails with a nested specific assertion failure on destination at target/i386/kvm.c +1629
-
-Migration is successful in the following cases-
-
-A) cpu model is 'host' and kvm is inserted without nested=1 parameter
-B) If instead of 'host' cpu model, 'kvm64' is used (KVM nested=1)
-C) If instead of 'host' cpu model, 'kvm64' is used (KVM nested=0)
-D) Between an L0 and a guest Hypervisor L1, with 'kvm64' as CPU type (and nested=1 for L0 KVM)
-
-Physical host(s)-
-$ lscpu
-Architecture:          x86_64
-CPU op-mode(s):        32-bit, 64-bit
-Byte Order:            Little Endian
-CPU(s):                12
-On-line CPU(s) list:   0-11
-Thread(s) per core:    1
-Core(s) per socket:    6
-Socket(s):             2
-NUMA node(s):          2
-Vendor ID:             GenuineIntel
-CPU family:            6
-Model:                 62
-Model name:            Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
-Stepping:              4
-CPU MHz:               1200.091
-CPU max MHz:           2600.0000
-CPU min MHz:           1200.0000
-BogoMIPS:              4203.28
-Virtualization:        VT-x
-L1d cache:             32K
-L1i cache:             32K
-L2 cache:              256K
-L3 cache:              15360K
-NUMA node0 CPU(s):     0-5
-NUMA node1 CPU(s):     6-11
-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 pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts
-
-Hi,
-  Can you please give the exact assertion failure.
-
-However, I'm confused - I think you're saying that your setup is that both hosts have nested enabled, but this is a migration of top level VM - correct?  Does the top level VM have a guest inside it - migration with a nested guest is known not to work, however migration of a VM on a host with nested enabled should work if the guest doesn't use the nest.
-
-
-Hello,
-I could not replicate this behavior on another system.
-So, please close this bug.
-Apologies for the inconvenience.
-
-Hmm OK; but if you do hit it again please just reopen this one and give the full assert and details
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1712818 b/results/classifier/deepseek-1/output/hypervisor/1712818
deleted file mode 100644
index fceec028..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1712818
+++ /dev/null
@@ -1,72 +0,0 @@
-
-live migration with storage encounter assert(!(bs->open_flags & BDRV_O_INACTIVE)) crashes
-
-The vm guest runs a iotest program, and i migrate it with virsh --copy-storage-all,then the qemu process on the source host happens to crash with the following message:
-
-kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed.
-2017-08-24 11:43:45.919+0000: shutting down, reason=crashed
-
-
-here is the release:
-qemu 2.7 & 2.10.rc3 were tested.
-libvirt 3.0.0 & 3.2.0 were tested.
-
-command line:
-src_host:virsh migrate --verbose --live --persistent --copy-storage-all vm-core qemu+ssh://dst_host/system
-
-Resaon: After bdrv_inactivate_all() was called, mirror_run coroutine stills write the left dirty disk data to remote nbd server, which triggers the assertion. But I don't known how to avoid the problem, help is needed!  Thanks.
-
-On 08/24/2017 07:59 AM, meeho yuen wrote:
-> Public bug reported:
-> 
-> The vm guest runs a iotest program, and i migrate it with virsh --copy-
-> storage-all,then the qemu process on the source host happens to crash
-> with the following message:
-> 
-> kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed.
-> 2017-08-24 11:43:45.919+0000: shutting down, reason=crashed
-
->   here is the release:
->   qemu 2.7 & 2.10.rc3 were tested.
-
-The just-tagged 2.10-rc4 includes a fix that should be addressing that
-issue during live migration; can you please re-test with that?  (see
-also https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg04513.html)
-
--- 
-Eric Blake, Principal Software Engineer
-Red Hat, Inc.           +1-919-301-3266
-Virtualization:  qemu.org | libvirt.org
-
-
-
-Thank you,I will try it.
-
-hi,eblake,the problem still exists on qemu 2.10_rc4,although the possibility is less than before.
-
-
-kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed.
-2017-08-25 11:08:18.963+0000: shutting down, reason=crashed
-
-
-I see the same thing:
-
-2017-12-28 21:36:26.837+0000: initiating migration
-qemu-system-x86_64: block/io.c:1537: bdrv_co_pwritev: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed.
-2017-12-28 21:36:40.516+0000: shutting down, reason=crashed
-~
-
-Running:
-QEMU emulator version 2.10.1
-libvirtd (libvirt) 3.10.0
-
-
-
-It seems that the following commit for libvirt fixed the problem.
-https://github.com/libvirt/libvirt/blob/960326237764f8970250a3608e7b2b880e030715/src/qemu/qemu_migration.c
-
-
-Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1715573 b/results/classifier/deepseek-1/output/hypervisor/1715573
deleted file mode 100644
index e1eeee1d..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1715573
+++ /dev/null
@@ -1,15 +0,0 @@
-
-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.
-
-This is maybe a duplicate of https://bugs.launchpad.net/qemu/+bug/1714331 ... could you please try a newer version of the OVMF firmware (if you're using it)?
-
-It works with a newer OVMF version!
-
-Thank you.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1723488 b/results/classifier/deepseek-1/output/hypervisor/1723488
deleted file mode 100644
index a66d1e89..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1723488
+++ /dev/null
@@ -1,74 +0,0 @@
-
-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
-
-It seems that HAX not working at all:
-
-qemu-system-x86_64.exe -accel hax -fda /opt/iso/freedos.img
-(with image of boot floppy from official FreeDOS site)
-
-Crash on loading with:
-
-VCPU shutdown request
-VCPU shutdown request
-VCPU shutdown request
-VCPU shutdown request
-VCPU shutdown request
-VCPU shutdown request
-VCPU shutdown request
-
-qemu-system-x86_64.exe -accel hax -cdrom /opt/iso/ubuntu-17.04-server-amd64.iso, hang on:
-
-Booting from DVD/CD...
-
-ISOLINUX 6.03 20170128 ETCD
-
-See https://software.intel.com/en-us/android/articles/installation-instructions-for-intel-hardware-accelerated-execution-manager-windows:
-
-"QEMU or Android Emulator will fail to launch if the guest RAM size (specified with the -m option for QEMU or -memory for Android Emulator) exceeds 4095MB."
-
-HAX is limited to a 32 bit memory size. There is no way to change that without breaking compatibility.
-
-The main problem is that HAX currently doesn't work properly at all on my both Windows 8.1 and Mac OS X 10.12.6 machines. 
-I can give other examples  if it is necessary
-
-Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1723984 b/results/classifier/deepseek-1/output/hypervisor/1723984
deleted file mode 100644
index 5e253914..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1723984
+++ /dev/null
@@ -1,47 +0,0 @@
-
-ID_MMFR0 has an invalid value on aarch64 cpu (A57, A53)
-
-The ID_MMFR0 register, accessed from aarch64 state as an invalid value:
-- ARM ARM v8 documentation (D7.2 General system control registers) described bits AuxReg[23:20] to be
-  "In ARMv8-A the only permitted value is 0010"
-- Cortex A53 and Cortex A57 TRM describe the value to be 0x10201105, so AuxReg[23:20] is 0010 too
-- in QEMU target/arm/cpu64.c, the relevant value is
-  cpu->id_mmfr0 = 0x10101105;
-
-The 1 should be changed to 2.
-
-Spotted & Tested on the following qemu revision:
-
-commit 48ae1f60d8c9a770e6da64407984d84e25253c69
-Merge: 78b62d3 b867eaa
-Author: Peter Maydell <email address hidden>
-Date:   Mon Oct 16 14:28:13 2017 +0100
-
-QEMU's behaviour in this case is matching the hardware. We claim to model an r1p0 (based on the MIDR value we report), and for the r1p0 the A53 and A57 reported the ID_MMFR0 as 0x10101105 -- this is documented in the TRMs for that rev of the CPUs. r1p3 reports the 0x10201105 you describe, but this isn't the rev of the CPU we claim to be.
-
-In theory we could bump the rXpX but I'm not sure there's much point unless it's causing a real problem (we'd need to check what else might have changed between the two revisions).
-
-
-Oh I see. I didn't check older TRM since the ARM ARM was quite strict on the value, sorry.
-I'll read the MIDR to have a more robust code then. Thank you.
-
-You shouldn't need to read the MIDR at all.
-
-There are two sensible strategies for software I think:
-
- (1) trust the architectural statement that v8 implies that the AIFSR and ADFSR both exist -- AIUI both QEMU and the hardware implementations that report 0001 in this MMFR0 field do actually implement those registers, so this is safe.
-
- (2) read and pay attention to the AuxReg field, by handling 0001 as "only Auxiliary Control Register is supported, AIFSR and ADFSR are not supported". This will work fine too -- on implementations that report 0001 you may be not using the AIFSR/ADFSR but that's ok because on those implementations they only RAZ/WI anyhow so you couldn't do anything interesting with them anyway.
-
-If your code is genuinely v8 only then (1) is easiest. If you also need to support ARMv7 then (2) is best, because 0001 is a permitted value in ID_MMFR0 for an ARMv7 implementation, so you need to handle it regardless of the A53/A57 behaviour.
-
-Neither approach requires detecting and special casing A53/A57 revisions via the MIDR.
-
-
-I see your point. Thank you for the advice. I'm doing some low-level check to be sure to be on a known platform, so this midr based code is very localized. For the "core" of the kernel, I'm mostly using (1) as access to MMU registers are localized in armv7/armv8 specialized sub-directories.
-
-
-
-Thanks for the update -- I'm going to close this bug. (Incidentally, my experience with checks of the "insist we're on a known platform with ID register values we recognize" kind is that they're more trouble than they're worth, especially if you plan running the software in an emulator.)
-
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1747056 b/results/classifier/deepseek-1/output/hypervisor/1747056
deleted file mode 100644
index 558b7eb0..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1747056
+++ /dev/null
@@ -1,70 +0,0 @@
-
-FreeDOS / MS-Dos / Windows 3.11 cannot perform reboot with 'isapc' machine
-
-I was installing MS-Dos 6.22 + Windows 3.11 in preparation for running Microsoft Bob, and noticed that when they try to perform a reboot, they just get stuck. The console cursor stays flashing on/off, but the DOS prompt no longer responds to input.
-
-It is fairly easy to reproduce, even FreeDOS is impacted - download the FreeDOS bootable CDROM image, then
-
-$ qemu-img create demo.img 100MB
-
-$ qemu-system-x86_64 -machine isapc -cdrom ~/Downloads/FD12CD.iso  -hda demo.img  -monitor stdio
-
-Wait for the installer to startup, and then in the monitor console run
-
-  sendkey ctrl-alt-delete
-
-It will fail to reboot
-
-Testing shows this is a regression from QEMU 2.8.0 onwards, and git bisect further narrowed it down to a SEABIOS update
-
-commit 6e99f5741ff1b408ea76e6caf2bd4f76df4060e9 (HEAD, tag: pull-seabios-20161027-2, tag: pull-seabios-20161027-1, refs/bisect/bad)
-Author: Gerd Hoffmann <email address hidden>
-Date:   Thu Oct 27 16:42:28 2016 +0200
-
-    seabios: update to 1.10.0 release.
-
-Note that this seems particular to the "isapc" machine type - with the "pc" machine type, reboot still works
-
-I bisected seabios and found this seabios change to be the cause of the problem
-
-commit b837e68d5a6c1a5945513f1995875445a1594c8a (refs/bisect/bad)
-Author: Kevin O'Connor <email address hidden>
-Date:   Mon Nov 9 15:00:19 2015 -0500
-
-    resume: Make KVM soft reboot loop detection more flexible
-    
-    Move the check for soft reboot loops from resume.c to shadow.c and
-    directly check for the case where the copy of the BIOS in flash
-    appears to be a memory alias instead.  This prevents a hang if an
-    external reboot request occurs during the BIOS memcpy.
-    
-    Signed-off-by: Kevin O'Connor <email address hidden>
-
-
-We need to pull in a SeaBIOS update with this fix applied to resolve this
-
-commit 42812e062a77b27b0544c8e0d46d206afc3b2fae
-Author: Kevin O'Connor <email address hidden>
-Date:   Thu Feb 22 20:29:27 2018 -0500
-
-    shadow: Don't invoke a shutdown on reboot unless in a reboot loop
-    
-    Old versions of KVM would map the same writable copy of the BIOS at
-    both 0x000f0000 and 0xffff0000.  As a result, a reboot on these
-    machines would result in a reboot loop.  So, the code attempts to
-    check for that situation and invoke a shutdown instead.
-    
-    Commit b837e68d changed the check to run prior to the first reboot.
-    However, this broke reboots on the QEMU isapc machine type.  Change
-    the reboot loop check to only be invoked after at least one reboot has
-    been attempted.
-    
-    Reported-by: Daniel P. Berrangé <email address hidden>
-    Signed-off-by: Kevin O'Connor <email address hidden>
-
-
-The SeaBIOS update mentioned by Daniel has been included here:
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0b8f74488e50f
-
-So I assume this bug is fixed, thus closing this now. If you still can reproduce it with the latest version of QEMU, then please complain.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1761535 b/results/classifier/deepseek-1/output/hypervisor/1761535
deleted file mode 100644
index 7342181d..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1761535
+++ /dev/null
@@ -1,56 +0,0 @@
-
-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>
-
-Could you provide a binary that we can use to reproduce, please? (preferably a setup that doesn't require me to figure out how to install and use docker...)
-
-
-I realized I had a javac lying around from last time somebody wanted me to debug a java problem, and I'm also seeing SEGVs with simpler programs like ls (!), so I'll have a look at those and hopefully that will be the same cause as what you're seeing.
-
-
-I think this should be fixed by https://patchwork.ozlabs.org/patch/896295/
-
-(incidentally the segfault is in the guest /bin/sh, not in javac or ls.)
-
-
-Now fixed in master, commit 7f0f4208b3a96, and will be in 2.12.0.
-
-
-Many thanks!
-
-I've just compiled master, and docker/aarch64/openjdk image now works as expected on my x86 machine.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1785972 b/results/classifier/deepseek-1/output/hypervisor/1785972
deleted file mode 100644
index 1bf332fe..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1785972
+++ /dev/null
@@ -1,78 +0,0 @@
-
-v3.0.0-rc4: VM fails to start after vcpuhotunplug, managedsave sequence
-
-VM fails to start after vcpu hot un-plug, managedsave sequence
-
-Host info:
-Kernel: 4.18.0-rc8-00002-g1236568ee3cb
-
-qemu: commit 6ad90805383e6d04b3ff49681b8519a48c9f4410 (HEAD -> master, tag: v3.0.0-rc4)
-QEMU emulator version 2.12.94 (v3.0.0-rc4-dirty)
-
-libvirt: commit 087de2f5a3dffb27d2eeb0c50a86d5d6984e5a5e (HEAD -> master)
-libvirtd (libvirt) 4.6.0
-
-Guest Kernel: 4.18.0-rc8-00002-g1236568ee3cb
-
-
-Steps to reproduce:
-1. Start a guest(VM) with 2 current , 4 max vcpus
-virsh start vm1
-Domain vm1 started
-
-2. Hotplug 2 vcpus
-virsh setvcpus vm1 4 --live
-
-3. Hot unplug 2 vcpus
-virsh setvcpus vm1 2 --live
-
-4. Managedsave the VM
-virsh managedsave vm1
-
-Domain vm1 state saved by libvirt
-
-5. Start the VM ---Fails to start
-virsh start vm1
-
-error: Failed to start domain avocado-vt-vm1
-error: internal error: qemu unexpectedly closed the monitor: 2018-08-08T06:27:53.853818Z qemu: Unknown savevm section or instance 'spapr_cpu' 2
-2018-08-08T06:27:53.854949Z qemu: load of migration failed: Invalid argument
-
-
-
-Testcase:
-avocado run libvirt_vcpu_plug_unplug.positive_test.vcpu_set.live.vm_operate.managedsave_with_unplug --vt-type libvirt --vt-extra-params emulator_path=/usr/share/avocado-plugins-vt/bin/qemu create_vm_libvirt=yes kill_vm_libvirt=yes env_cleanup=yes smp=8 backup_image_before_testing=no libvirt_controller=virtio-scsi scsi_hba=virtio-scsi-pci drive_format=scsi-hd use_os_variant=no restore_image_after_testing=no vga=none display=nographic kernel=/home/kvmci/linux/vmlinux kernel_args='root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init  initcall_debug' take_regular_screendumps=no --vt-guest-os JeOS.27.ppc64le
-JOB ID     : 1f869477ad87e7d7e7e7777f631ae08965f41a74
-JOB LOG    : /root/avocado/job-results/job-2018-08-08T02.42-1f86947/job.log
- (1/1) type_specific.io-github-autotest-libvirt.libvirt_vcpu_plug_unplug.positive_test.vcpu_set.live.vm_operate.managedsave_with_unplug: ERROR (91.58 s)
-RESULTS    : PASS 0 | ERROR 1 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0
-JOB TIME   : 95.89 s
-
-
-
-Bisect result:
-
-v3.0.0-rc0: vcpu hotplug crashes the domain - https://bugs.launchpad.net/qemu/+bug/1780928, this commit fixes that issue, b585395b655a6c1f9d9ebf1f0890e76d0708eed6 ppc/xics: fix ICP reset path
-
-
-v3.0.0-rc1- v3.0.0-rc4: hotplug crash bug fixed, but now we are hitting this one.
-
-Last good commit I could find, 2309832afdaf8d6451ebc2e81bace8eb8ea41293 where both vcpu hotplug and managed save sequence worked fine.
-
-The first commit that causes this issue is:
-
-b94020268e0b6659499e250d25346baaa9888fed (spapr_cpu_core: migrate per-CPU data)
-
-Simpler way to reproduce:
-1. Hotplug a CPU
-2. Hot unplug it
-3. Migrate the VM (will fail)
-
-This commit https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg01281.html from ~bharata-rao, fixes the issue.
-
-Applied to ppc-for-3.1.
-
-https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg01317.html
-
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc71c7760e263f808c4240a
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1811543 b/results/classifier/deepseek-1/output/hypervisor/1811543
deleted file mode 100644
index 187583fc..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1811543
+++ /dev/null
@@ -1,82 +0,0 @@
-
-virtio-scsi gives improper discard sysfs entries
-
-Apologies if this is just an inherent part of paravirtualization that should be expected.
-
-In my host, I have an LVM thin pool with chunk_size 128MB.  Within it, I have a thin volume "tmp".  In the host:
-
-# fdisk -l /dev/lvm/tmp
-Disk /dev/lvm/tmp: 256 MiB, 268435456 bytes, 524288 sectors
-Units: sectors of 1 * 512 = 512 bytes
-Sector size (logical/physical): 512 bytes / 4096 bytes
-I/O size (minimum/optimal): 262144 bytes / 134217728 bytes
-Disklabel type: gpt
-Disk identifier: BAE3154E-6E85-F642-8129-BAD7B58B2775
-
-Device        Start    End Sectors  Size Type
-/dev/lvm/tmp1  2048 524254  522207  255M Linux filesystem
-
-$ lsblk
-...
-      └─lvm-tmp                      254:13   0   256M  0 lvm
-        └─lvm-tmp1                   254:14   0   255M  0 part
-
-$ cat /sys/dev/block/254:13/discard_alignment
-0
-$ cat /sys/dev/block/254:13/queue/discard_granularity
-134217728
-$ cat /sys/dev/block/254:13/queue/discard_max_bytes
-17179869184
-$ cat /sys/dev/block/254:13/queue/discard_max_hw_bytes
-0
-$ cat /sys/dev/block/254:13/queue/discard_zeroes_data
-0
-
-$ cat /sys/dev/block/254:14/discard_alignment
-133169152
-$ cat /sys/dev/block/254:14/queue/discard_granularity
-134217728
-$ cat /sys/dev/block/254:14/queue/discard_max_bytes
-17179869184
-$ cat /sys/dev/block/254:14/queue/discard_max_hw_bytes
-0
-$ cat /sys/dev/block/254:14/queue/discard_zeroes_data
-0
-
-If this is given to QEMU using virtio-scsi:
-
-   -device virtio-scsi-pci,id=scsi1 \
-   -drive driver=raw,node-name=hdb,file=/dev/lvm/tmp,if=none,discard=unmap,id=hd2 \
-   -device scsi-hd,drive=hd2,bootindex=1 \
-
-Then incorrect values are given:
-
-$ lsblk
-...
-sdb     8:16   0   256M  0 disk
-└─sdb1  8:17   0   255M  0 part /mnt
-
-$ cat /sys/dev/block/8:16/discard_alignment
-0
-$ cat /sys/dev/block/8:16/queue/discard_granularity
-4096
-$ cat /sys/dev/block/8:16/queue/discard_max_bytes
-1073741824
-$ cat /sys/dev/block/8:16/queue/discard_max_hw_bytes
-1073741824
-$ cat /sys/dev/block/8:16/queue/discard_zeroes_data
-0
-
-$ cat /sys/dev/block/8:17/discard_alignment
-133169152
-
-And, there isn't even a /sys/dev/block/8:17/queue direcotry.
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/161
-
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1817846 b/results/classifier/deepseek-1/output/hypervisor/1817846
deleted file mode 100644
index 5d4820db..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1817846
+++ /dev/null
@@ -1,56 +0,0 @@
-
-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
-
-Could you provide a test binary (and the QEMU command line to run it) that demonstrates the bug, please?
-
-
-Marking bug as incomplete -- we can't investigate without a test case.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1826599 b/results/classifier/deepseek-1/output/hypervisor/1826599
deleted file mode 100644
index 06e03119..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1826599
+++ /dev/null
@@ -1,20 +0,0 @@
-
-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
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1832535 b/results/classifier/deepseek-1/output/hypervisor/1832535
deleted file mode 100644
index 62992e74..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1832535
+++ /dev/null
@@ -1,26 +0,0 @@
-
-[riscv/regression] Missing tlb flush introduced in refactoring
-
-Hello,
-
-In qemu-system-riscv64, following a QEMU update, I get all sort of weird and not easily reproducible crashes in my risc-v guest.
-
-I have bissected this issue to commit c7b951718815694284501ed01fec7acb8654db7b.
-Some TLB flushes were removed in the following places:
-target/riscv/cpu_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice)
-target/riscv/op_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice)
-
-Adding TLB flushes in all 4 places fixes the issues for me.
-
-Hello,
-
-Thanks for reporting a bug.
-
-Can you please include details to reproduce the problems that you are seeing? This includes images and command line arguments.
-
-Do you also mind including the diff of what fixes the problem for you?
-
-Alistair
-
-It has been solved thanks to the mailing-list members.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1850378 b/results/classifier/deepseek-1/output/hypervisor/1850378
deleted file mode 100644
index 3b403164..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1850378
+++ /dev/null
@@ -1,41 +0,0 @@
-
-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.
-
-Can you post a whole program that reproduces this?  freedom-e-sdk <https://github.com/sifive/freedom-e-sdk> will run bare-metal code on QEMU if you don't want to post the rest of the surrounding infrastructure.
-
-I created a minimal example from my setup. I'm running a kernel 4.19.57 with a custom firmware based on bbl (https://github.com/riscv/riscv-pk). 
-An ioctl device from a kernel module is used to execute the code above in kernel space.
-In the example, the userspace application proceeds after a couple of seconds without receiving the custom IPI.
-
-The QEMU project is currently considering to move its bug tracking to
-another system. For this we need to know which bugs are still valid
-and which could be closed already. Thus we are setting older bugs to
-"Incomplete" now.
-
-If you still think this bug report here is valid, then please switch
-the state back to "New" within the next 60 days, otherwise this report
-will be marked as "Expired". Or please mark it as "Fix Released" if
-the problem has been solved with a newer version of QEMU already.
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1855002 b/results/classifier/deepseek-1/output/hypervisor/1855002
deleted file mode 100644
index bc710426..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1855002
+++ /dev/null
@@ -1,35 +0,0 @@
-
-Cannot boot arm kernel images on s390x
-
-While running the acceptance tests on s390x, the arm tests under qemu/tests/acceptance/boot_linux_console.py will timeout, except the test using u-boot. All the arm tests run without problems on x86 and ppc.
-
-This test boots the kernel and wait for a kernel panic to make sure it can boot that kind of kernel on the host running the test. The URL for the kernels are available inside the python test code, but I'm listing them here:
-
-Fail: https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/armhfp/os/images/pxeboot/vmlinuz
-Fail: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb
-Fail: https://snapshot.debian.org/archive/debian/20190928T224601Z/pool/main/l/linux/linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb
-Pass: https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test-binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/spi.bin
-
-I tried to manually investigate the problem with the first kernel of the list. The command I used to try to boot it was:
-
-/home/linux1/src/v4.2.0-rc3/bin/qemu-system-arm -serial stdio -machine virt -kernel /home/linux1/venv/python3/data/cache/by_location/1d5fdf8018e79b806aa982600c0866b199946efc/vmlinuz
--append "printk.time=0 console=ttyAMA0"
-
-On an x86 machine, I can see it boots and ends with a kernel panic as expected. On s390x, it just hangs.
-
-I also tried to debug with gdb, redirecting the monitor and the serial console to other terminal sessions without success.
-
-QEMU version is the latest as of today,tag v4.2.0-rc4, commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e.
-
-s390x system is a Red Hat Enterprise Linux Server 7.7 running as a z/VM 6.4.0 guest at IBM LinuxONE Community Cloud.
-
-x86 system is a Fedora 31 running on Intel i7-8650U.
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/187
-
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1855072 b/results/classifier/deepseek-1/output/hypervisor/1855072
deleted file mode 100644
index 410fb97e..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1855072
+++ /dev/null
@@ -1,25 +0,0 @@
-
-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.
-
-Yes to both.
-
-Patch posted:
-https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg04401.html
-
-If you could help testing, that would be appreciated.
-
-Thank you for the patch! I am happy to test this for you. I will apply the patch/compile/test and get back to you.
-
-I tested in AArch64 mode and it worked for me. Looking at the patch, we might be missing trapping for "TTBCR"in AA32 though.
-
-Oops.  Thanks for the review.  Posted v2 with ttbcr included.
-
-Thank you! I also tested AArch32 and the code works. Ship it!
-
-Fixed here:
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=84929218512c
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1855617 b/results/classifier/deepseek-1/output/hypervisor/1855617
deleted file mode 100644
index dc678c6c..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1855617
+++ /dev/null
@@ -1,62 +0,0 @@
-
-savevm with hax saves wrong register state
-
-I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different.
-When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot.
-
-cc'ing Colin and Yu for Hax info:
-
-* Alex (<email address hidden>) wrote:
-> Public bug reported:
-> 
-> I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different.
-> When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot.
-> 
-> ** Affects: qemu
->      Importance: Undecided
->          Status: New
-> 
-> -- 
-> You received this bug notification because you are a member of qemu-
-> devel-ml, which is subscribed to QEMU.
-> https://bugs.launchpad.net/bugs/1855617
-> 
-> Title:
->   savevm with hax saves wrong register state
-> 
-> Status in QEMU:
->   New
-> 
-> Bug description:
->   I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different.
->   When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot.
-> 
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1855617/+subscriptions
-> 
---
-Dr. David Alan Gilbert / <email address hidden> / Manchester, UK
-
-
-
-The QEMU project is currently considering to move its bug tracking to
-another system. For this we need to know which bugs are still valid
-and which could be closed already. Thus we are setting older bugs to
-"Incomplete" now.
-
-If you still think this bug report here is valid, then please switch
-the state back to "New" within the next 60 days, otherwise this report
-will be marked as "Expired". Or please mark it as "Fix Released" if
-the problem has been solved with a newer version of QEMU already.
-
-Thank you and sorry for the inconvenience.
-
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/188
-
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1861653 b/results/classifier/deepseek-1/output/hypervisor/1861653
deleted file mode 100644
index bf87cd8f..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1861653
+++ /dev/null
@@ -1,53 +0,0 @@
-
-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)
-
-The QEMU project is currently considering to move its bug tracking to
-another system. For this we need to know which bugs are still valid
-and which could be closed already. Thus we are setting older bugs to
-"Incomplete" now.
-
-If you still think this bug report here is valid, then please switch
-the state back to "New" within the next 60 days, otherwise this report
-will be marked as "Expired". Or please mark it as "Fix Released" if
-the problem has been solved with a newer version of QEMU already.
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1863685 b/results/classifier/deepseek-1/output/hypervisor/1863685
deleted file mode 100644
index 52a234b8..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1863685
+++ /dev/null
@@ -1,36 +0,0 @@
-
-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.
-
-Patch posted:
-https://<email address hidden>/
-
-Thanks for the quick turn around! I tested both your patches together (it's useful to have both to emulate set/way flushing inside a guest) and I am getting something unexpected. At some point, we are trapping on an access to DACR but ESR_EL2 doesn't seem to make a lot of sense: 0xfe00dc0. I am running a 32-bit Linux inside a VM.
-
-Decoding it: Rt is set to 0xe which is LR_usr. Also, this is a read operation. So, essentially the guest seems to try to set DACR to LR_usr which seems unreasonable.
-
-It could be an issue with the hypervisor on my side (I am running some custom code). But, it's not obvious to me and the code behaves fine on bare-metal. Is there a chance that ESR is not populated correctly?
-
-In any case, I do see traps for set/way instructions so, from that point of view, the patch is good.
-
-
-
-Sorry, I meant the operation is a write (TVM is on). The result of the operation is setting DACR to 0 so the guest stops progressing after that.
-
-Anyway, since the issue could also be on my side, I don't want to block you with this. 
-
-I can't think of any reason that DACR would have an incorrect
-register value.  It would be treated as any other system register,
-and there's only one code path involved.
-
-Makes sense. Debugging is on me then :) Both patches behave as expected, thanks!
-
-Fixed here:
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1803d2713b29
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1872644 b/results/classifier/deepseek-1/output/hypervisor/1872644
deleted file mode 100644
index b9d2f385..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1872644
+++ /dev/null
@@ -1,60 +0,0 @@
-
-MacOS host qemu-system-x86_64 -cpu host not working
-
-MacOS: 10.15.4
-uname -a: Linux door 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
-
-I am using qemu on mac host, with ubuntu client.
-
-I used to have "-cpu host" in my qemu command as follow:-
-
-qemu-system-x86_64 \
--no-user-config \
--nodefaults \
--name u64d01 \
--show-cursor \
--M q35,accel=hvf,usb=off,vmport=off \
--cpu host \
--m 8192M \
--smp 4 \
--rtc base=utc,clock=host \
--device virtio-blk-pci,drive=ssd1 \
--drive id=ssd1,file=/Users/js/code/vm/qemu/u64d01.qcow2,if=none,format=qcow2 \
--device virtio-net-pci,netdev=nic1,mac=52:54:98:76:54:33 \
--netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 \
--device virtio-tablet-pci \
--device virtio-vga \
--device ich9-intel-hda,id=snd,msi=on \
--device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \
--audiodev coreaudio,id=snd0
-
-Base on log of one of the vm, it was definitely working on 2020-01-17(base on journal inside vm), with qemu 4.2.0, which I installed with brew.
-
-The only way to make it work is to remove "-cpu host".
-
-Already tried with 4.1.1, 4.2 and 5.0rc2. Same result.
-
-To reproduce, try above with a Ubuntu 18.04 installation cd. Client will crash during kernel loading.
-
-
-
-I found that things were unstable unless the following were also added
--cpu Nehalem,-rdtscp
-(the CPU can be higher than Nehalem but obviously your host CPU actually has to be equal or greater too)
-
--rdtscp is a known issue that has since been workedaround (see bug #1894836 ).
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting older bugs to "Incomplete" now.
-
-If you still think this bug report here is valid, then please switch
-the state back to "New" within the next 60 days, otherwise this report
-will be marked as "Expired". Or please mark it as "Fix Released" if
-the problem has been solved with a newer version of QEMU already.
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1875702 b/results/classifier/deepseek-1/output/hypervisor/1875702
deleted file mode 100644
index 3d4df16b..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1875702
+++ /dev/null
@@ -1,32 +0,0 @@
-
-madvise reports success, but doesn't implement WIPEONFORK.
-
-The implementation of madvise (linux-user/syscall.c:11331, tag v5.0.0-rc4) always returns zero (i.e. success). However, an application requesting (at least) MADV_WIPEONFORK may need to know whether the call was actually successful. If not (because the kernel doesn't support WIPEONFORK) then it will need to take other measures to provide fork-safety (such as drawing entropy from the kernel in every case). But, if the application believes that WIPEONFORK is supported (because madvise returned zero), but it actually isn't (as in qemu), then it may forego those protections on the assumption that WIPEONFORK will provide fork-safety.
-
-Roughly, the comment in qemu that says "This is a hint, so ignoring and returning success is ok." is no longer accurate in the presence of MADV_WIPEONFORK.
-
-(This is not purely academic: BoringSSL is planning on acting in this way. We found the qemu behaviour in pre-release testing and are planning on making an madvise call with advice=-1 first to test whether unknown advice values actually produce EINVAL.)
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting older bugs to "Incomplete" now.
-
-If you still think this bug report here is valid, then please switch
-the state back to "New" within the next 60 days, otherwise this report
-will be marked as "Expired". Or please mark it as "Fix Released" if
-the problem has been solved with a newer version of QEMU already.
-
-Thank you and sorry for the inconvenience.
-
-
-Still relevant. See also bug #1926521 -- MADV_DONTNEED is another madvise() value that can't be ignored as "just a hint".
-
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/343
-
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1877688 b/results/classifier/deepseek-1/output/hypervisor/1877688
deleted file mode 100644
index f04cc052..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1877688
+++ /dev/null
@@ -1,40 +0,0 @@
-
-9p virtfs device reports error when opening certain files
-
-Reading certain files on a 9p mounted FS produces this error message:
-
-qemu-system-x86_64: VirtFS reply type 117 needs 12 bytes, buffer has 12, less than minimum
-
-After this error message is generated, further accesses to the 9p FS hangs whatever tries to access it. The Arch Linux guest system is otherwise usable. This happens with QEMU 5.0.0 and guest kernel version 5.6.11, hosted on an Arch Linux distro. I use the following command to launch QEMU:
-
-exec qemu-system-x86_64 -enable-kvm -display gtk -vga virtio -cpu host -m 4G -netdev tap,ifname=vmtap0,id=vn0,script=no,downscript=no -device virtio-net-pci,netdev=vn0 -kernel kernel.img -drive file=file.img,format=raw,if=virtio -virtfs local,path=mnt,mount_tag=host0,security_model=passthrough,id=host0 -append "console=ttyS0 root=/dev/vda rw"
-
-There's nothing relevant in the guest kernel logs as far as I'm aware of with loglevel set to 7.
-
-Here's a C program to trigger this behavior. I don't think it matters what the contents of "file" or its size is.
-
-Looks like being introduced by this change:
-https://patchwork.kernel.org/patch/11319993/
-
-More specifically this one exactly:
-
--    if (buf_size  < size) {
-+    if (buf_size  < P9_IOHDRSZ) {
-
-
-
-The following patch should fix this bug for the kvm backend (not for the XEN backend yet).
-
-Please let me know if it fixes this bug for you.
-
-Thanks, it works.
-
-Fix is now committed on master as SHA-1 cf45183b718f02b1369e18c795dc51bc1821245d, which actually just reverted the mentioned commit that was leading to this broken behavior:
-https://github.com/qemu/qemu/commit/cf45183b718f02b1369e18c795dc51bc1821245d
-
-The original Xen transport bug that motivated that change, was now fixed differently by handling that Xen issue solely on Xen transport driver side:
-https://github.com/qemu/qemu/commit/a4c4d462729466c4756bac8a0a8d77eb63b21ef7
-
-
-Fixed in QEMU 5.1 release.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1885553 b/results/classifier/deepseek-1/output/hypervisor/1885553
deleted file mode 100644
index f4099fe4..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1885553
+++ /dev/null
@@ -1,45 +0,0 @@
-
-make-check test failed with "Segmentation fault"
-
-While running the make-check testing on arm architecture the test failed with error:
-"kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core dumped)". Apart from that make-install test always passes.
-The problem doesn't reproduce in 100%
-qemu - from the master branch
-RHEL-8 kernel 4.18.0-221.el8.aarch64
-Logfile with an error you can to find in attachment
-
-Thanks
-
-
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting the bug state to "Incomplete" now.
-
-If the bug has already been fixed in the latest upstream version of QEMU,
-then please close this ticket as "Fix released".
-
-If it is not fixed yet and you think that this bug report here is still
-valid, then you have two options:
-
-1) If you already have an account on gitlab.com, please open a new ticket
-for this problem in our new tracker here:
-
-    https://gitlab.com/qemu-project/qemu/-/issues
-
-and then close this ticket here on Launchpad (or let it expire auto-
-matically after 60 days). Please mention the URL of this bug ticket on
-Launchpad in the new ticket on GitLab.
-
-2) If you don't have an account on gitlab.com and don't intend to get
-one, but still would like to keep this ticket opened, then please switch
-the state back to "New" within the next 60 days (otherwise it will get
-closed as "Expired"). We will then eventually migrate the ticket auto-
-matically to the new system (but you won't be the reporter of the bug
-in the new system and thus won't get notified on changes anymore).
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1904317 b/results/classifier/deepseek-1/output/hypervisor/1904317
deleted file mode 100644
index 8324c20c..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1904317
+++ /dev/null
@@ -1,90 +0,0 @@
-
-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.
-
-Cc'ing Sunil (WHPX maintainer).
-
-On 11/15/20 10:06 AM, Takumi Nakamura wrote:
-> Public bug reported:
-> 
-> 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.
-> 
-> ** Affects: qemu
->      Importance: Undecided
->          Status: New
-> 
-
-
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting the bug state to "Incomplete" now.
-
-If the bug has already been fixed in the latest upstream version of QEMU,
-then please close this ticket as "Fix released".
-
-If it is not fixed yet and you think that this bug report here is still
-valid, then you have two options:
-
-1) If you already have an account on gitlab.com, please open a new ticket
-for this problem in our new tracker here:
-
-    https://gitlab.com/qemu-project/qemu/-/issues
-
-and then close this ticket here on Launchpad (or let it expire auto-
-matically after 60 days). Please mention the URL of this bug ticket on
-Launchpad in the new ticket on GitLab.
-
-2) If you don't have an account on gitlab.com and don't intend to get
-one, but still would like to keep this ticket opened, then please switch
-the state back to "New" or "Confirmed" within the next 60 days (other-
-wise it will get closed as "Expired"). We will then eventually migrate
-the ticket automatically to the new system (but you won't be the reporter
-of the bug in the new system and thus you won't get notified on changes
-anymore).
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1916775 b/results/classifier/deepseek-1/output/hypervisor/1916775
deleted file mode 100644
index f7be581a..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1916775
+++ /dev/null
@@ -1,93 +0,0 @@
-
-Guest freezes until there is a keyboard input on Windows version
-
-Windows guests are freezing and waiting for keyboard input and it continues to function after I press a key. I am using Windows10 Home and below is the command I use to run the guest. I have suspected if this is caused by random entropy but even with mouse moving it gives same random locks and it continues to work as soon as I press a key so maybe its not about entropy at all,
-
-startwinguest.bat:
-qemu-system-x86_64 ^
- -name "win" ^
- -machine type=q35,accel=whpx ^
- -cpu EPYC,hv_relaxed,hv_time,topoext   ^
- -nodefaults ^
- -usb ^
- -rtc base=localtime,driftfix=slew ^
- -smp 6,sockets=1,cores=3,threads=2 ^
- -m 8192 -mem-prealloc ^
- -soundhw hda ^
- -usbdevice tablet ^
- -netdev user,id=mynet0,hostfwd=tcp::3390-:3389 -device virtio-net,netdev=mynet0 ^
- -vga std ^
- -display gtk ^
- -boot d ^
- -device virtio-scsi-pci,id=scsi0 ^
- -drive "file=%~dp0win10.qcow2,if=none,format=qcow2,discard=unmap,aio=threads,cache=writethrough,id=someid" ^
- -device scsi-hd,drive=someid,bus=scsi0.0 ^
- -drive "file=D:\Setups\OS\Windows\en_windows_server_2019_updated_dec_2020_x64_dvd_36e0f791.iso,media=cdrom,index=1" ^
- -drive "file=%~dp0virtio-win-0.1.185.iso,media=cdrom,index=2"
-
-I run into this behavior too. Win10 Home guest, PCI-passthrough graphics (GTX 1650), host cpu (Ryzen 7 3800XT). Occurs whether or not I use the qcow disk drive.
-
-qemu-system-x86_64 
-  -cpu host,kvm=on,l3-cache=on,hv_relaxed,hv_vapic,hv_time,hv_spinlocks=0x1fff,hv_vendor_id=hv_dummy 
-  -smp 8 
-  -rtc clock=host,base=localtime 
-  -machine type=q35,accel=kvm,kernel_irqchip=on 
-  -enable-kvm 
-  -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd 
-  -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd 
-  -m 32G 
-  -usb 
-  -device usb-tablet 
-  -vga none 
-  -serial none 
-  -parallel none 
-  -boot cd 
-  -nographic 
-  -device usb-host,vendorid=0x045e,productid=0x00db 
-  -device usb-host,vendorid=0x1bcf,productid=0x0005 
-  -drive id=disk0,index=0,format=qcow2,if=virtio,cache=off,file=./win10_boot_priv.qcow2 
-  -drive id=disk2,index=2,aio=native,cache.direct=on,if=virtio,cache=off,format=raw,discard=unmap,detect-zeroes=unmap,file=/dev/vg0/win10_hdpriv 
-  -device vfio-pci,host=09:00.0,addr=0x02.0x0,multifunction=on 
-  -device vfio-pci,host=09:00.1,addr=0x02.0x1 
-  -device vfio-pci,host=09:00.2,addr=0x02.0x2 
-  -device vfio-pci,host=09:00.3,addr=0x02.0x3 
-  -netdev tap,id=netid,ifname=taplan,script=no,downscript=no 
-  -device e1000,netdev=netid,mac=52:54:00:01:02:03
-
-
-PS - My host is Debian 4.19.171-2
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting the bug state to "Incomplete" now.
-
-If the bug has already been fixed in the latest upstream version of QEMU,
-then please close this ticket as "Fix released".
-
-If it is not fixed yet and you think that this bug report here is still
-valid, then you have two options:
-
-1) If you already have an account on gitlab.com, please open a new ticket
-for this problem in our new tracker here:
-
-    https://gitlab.com/qemu-project/qemu/-/issues
-
-and then close this ticket here on Launchpad (or let it expire auto-
-matically after 60 days). Please mention the URL of this bug ticket on
-Launchpad in the new ticket on GitLab.
-
-2) If you don't have an account on gitlab.com and don't intend to get
-one, but still would like to keep this ticket opened, then please switch
-the state back to "New" or "Confirmed" within the next 60 days (other-
-wise it will get closed as "Expired"). We will then eventually migrate
-the ticket automatically to the new system (but you won't be the reporter
-of the bug in the new system and thus you won't get notified on changes
-anymore).
-
-Thank you and sorry for the inconvenience.
-
-
-This ticket has been moved here (thanks, Abdurrahim):
-https://gitlab.com/qemu-project/qemu/-/issues/289
-... thus I'm closing this ticket on Launchpad now.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1917184 b/results/classifier/deepseek-1/output/hypervisor/1917184
deleted file mode 100644
index eb7b05f9..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1917184
+++ /dev/null
@@ -1,49 +0,0 @@
-
-qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip
-
-When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault.
-
-qemu version 5.2.0, x86-64 host.
-
-
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting the bug state to "Incomplete" now.
-
-If the bug has already been fixed in the latest upstream version of QEMU,
-then please close this ticket as "Fix released".
-
-If it is not fixed yet and you think that this bug report here is still
-valid, then you have two options:
-
-1) If you already have an account on gitlab.com, please open a new ticket
-for this problem in our new tracker here:
-
-    https://gitlab.com/qemu-project/qemu/-/issues
-
-and then close this ticket here on Launchpad (or let it expire auto-
-matically after 60 days). Please mention the URL of this bug ticket on
-Launchpad in the new ticket on GitLab.
-
-2) If you don't have an account on gitlab.com and don't intend to get
-one, but still would like to keep this ticket opened, then please switch
-the state back to "New" or "Confirmed" within the next 60 days (other-
-wise it will get closed as "Expired"). We will then eventually migrate
-the ticket automatically to the new system (but you won't be the reporter
-of the bug in the new system and thus you won't get notified on changes
-anymore).
-
-Thank you and sorry for the inconvenience.
-
-
-Bug still present in latest master
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/314
-
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1921061 b/results/classifier/deepseek-1/output/hypervisor/1921061
deleted file mode 100644
index 69cd3fcc..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1921061
+++ /dev/null
@@ -1,70 +0,0 @@
-
-Corsair iCUE Install Fails, qemu VM Reboots
-
-Hi,
-
-I had this working before, but in the latest version of QEMU (built from master), when I try to install Corsair iCUE, and it gets to the driver install point => my Windows 10 VM just reboots! I would be happy to capture logs, but ... what logs exist for an uncontrolled reboot? Thinking they are lost in the reboot :-(.
-
-Thanks!
-
-Hi,
-
-Slight update - as I decided to passthru my NIC as well => driver install there also causes a VM (Windows 10) reboot. Seems all driver installs fail?
-
-Running on the latest master, QEMU emulator version 5.2.93 (v6.0.0-rc3).
-
-Thanks!
-
-FYI, to provide an update - I found a workaround! It's related to the CPU selection. I can't seem to pass through my host CPU, even with v6.0.0 of qemu. Rather, I have to use the qemu64 CPU.
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting the bug state to "Incomplete" now.
-
-If the bug has already been fixed in the latest upstream version of QEMU,
-then please close this ticket as "Fix released".
-
-If it is not fixed yet and you think that this bug report here is still
-valid, then you have two options:
-
-1) If you already have an account on gitlab.com, please open a new ticket
-for this problem in our new tracker here:
-
-    https://gitlab.com/qemu-project/qemu/-/issues
-
-and then close this ticket here on Launchpad (or let it expire auto-
-matically after 60 days). Please mention the URL of this bug ticket on
-Launchpad in the new ticket on GitLab.
-
-2) If you don't have an account on gitlab.com and don't intend to get
-one, but still would like to keep this ticket opened, then please switch
-the state back to "New" or "Confirmed" within the next 60 days (other-
-wise it will get closed as "Expired"). We will then eventually migrate
-the ticket automatically to the new system (but you won't be the reporter
-of the bug in the new system and thus you won't get notified on changes
-anymore).
-
-Thank you and sorry for the inconvenience.
-
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/320
-
-
-Hi Russel, this bug has been migrated to the new GitLab issue tracker; can you provide me with some extra information over on the new tracker, please?
-
-(I am *very* likely to miss updates here.)
-
-1. What is your QEMU command line? (A full, working command-line, but the smallest one you can reproduce the problem with is helpful.)
-2. What is your host environment? (distro/linux kernel version, CPU model)
-3. What happens *exactly* when you try to install iCUE? Windows reboots -- in what way? Does it bluescreen, or does it just reboot immediately and then continue on as if nothing happened? Are there any errors/warnings/output from QEMU at all? Does QEMU crash?
-
-Some other information that might be helpful if you have it:
-
-4. Is there a version of QEMU where this works correctly for you still? Do you know when the problem appeared?
-5. Depending on exactly how the VM reboots, you *may* have information in your windows event viewer logs -- do you see any warnings or errors in there that might be relevant?
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1921082 b/results/classifier/deepseek-1/output/hypervisor/1921082
deleted file mode 100644
index 35442d7e..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1921082
+++ /dev/null
@@ -1,50 +0,0 @@
-
-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.
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting the bug state to "Incomplete" now.
-
-If the bug has already been fixed in the latest upstream version of QEMU,
-then please close this ticket as "Fix released".
-
-If it is not fixed yet and you think that this bug report here is still
-valid, then you have two options:
-
-1) If you already have an account on gitlab.com, please open a new ticket
-for this problem in our new tracker here:
-
-    https://gitlab.com/qemu-project/qemu/-/issues
-
-and then close this ticket here on Launchpad (or let it expire auto-
-matically after 60 days). Please mention the URL of this bug ticket on
-Launchpad in the new ticket on GitLab.
-
-2) If you don't have an account on gitlab.com and don't intend to get
-one, but still would like to keep this ticket opened, then please switch
-the state back to "New" or "Confirmed" within the next 60 days (other-
-wise it will get closed as "Expired"). We will then eventually migrate
-the ticket automatically to the new system (but you won't be the reporter
-of the bug in the new system and thus you won't get notified on changes
-anymore).
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1926044 b/results/classifier/deepseek-1/output/hypervisor/1926044
deleted file mode 100644
index cc506a42..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1926044
+++ /dev/null
@@ -1,121 +0,0 @@
-
-QEMU-user doesn't report HWCAP2_MTE
-
-Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a
-
-Host Debian 5.10.24 x86_64 GNU
-
-Configured with "configure --disable-system --enable-linux-user --static"
-
-This one works and prints "OK" as expected:
-clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu  -fsanitize=memtag -march=armv8+memtag
-qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK
-
-
-This one fails and print "0":
-cat mytest.c
-#include <stdio.h>
-#include <sys/auxv.h>
-
-#ifndef HWCAP2_MTE
-#define HWCAP2_MTE (1 << 18)
-#endif
-
-int main(int ac, char **av)
-{
-    printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE));
-}
-
-
-clang mytest.c -target aarch64-linux-gnu  -fsanitize=memtag -march=armv8+memtag
-qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out
-
-Actually if we make it like this:
-
-#include <stdio.h>
-#include <sys/auxv.h>
-
-int main(int ac, char **av)
-{
-    for (int i = 0; i < 32; ++i)
-        if ((int)(getauxval(AT_HWCAP2) & (1 << i)))
-            printf("%d\n", i);
-}
-
-
-clang mytest.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag
-qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out
-
-I see only: HWCAP_FP HWCAP_CRC32 HWCAP_ATOMICS
-So no HWCAP2_BTI as well.
-
-Sorry, 0 7 8 should be "HWCAP2_DCPODP HWCAP2_FLAGM2 HWCAP2_FRINT"
-
-Yep, there's a whole bunch that have been missed.
-
-https://<email address hidden>/
-
-This has missed 6.0, but should be acceptable to roll into 6.0.1.
-
-Thanks for the quick fix!
-
-On Tue, Apr 27, 2021 at 2:55 PM Richard Henderson <
-<email address hidden>> wrote:
-
->
-> https://<email address hidden>/
->
-> This has missed 6.0, but should be acceptable to roll into 6.0.1.
->
-> --
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1926044
->
-> Title:
->   QEMU-user doesn't report HWCAP2_MTE
->
-> Status in QEMU:
->   In Progress
->
-> Bug description:
->   Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a
->
->   Host Debian 5.10.24 x86_64 GNU
->
->   Configured with "configure --disable-system --enable-linux-user
->   --static"
->
->   This one works and prints "OK" as expected:
->   clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu
-> -fsanitize=memtag -march=armv8+memtag
->   qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK
->
->
->   This one fails and print "0":
->   cat mytest.c
->   #include <stdio.h>
->   #include <sys/auxv.h>
->
->   #ifndef HWCAP2_MTE
->   #define HWCAP2_MTE (1 << 18)
->   #endif
->
->   int main(int ac, char **av)
->   {
->       printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE));
->   }
->
->
->   clang mytest.c -target aarch64-linux-gnu  -fsanitize=memtag
-> -march=armv8+memtag
->   qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out
->
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1926044/+subscriptions
->
-
-
-Patch has been merged:
-https://gitlab.com/qemu-project/qemu/-/commit/68948d18224b93361e28
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/1952448 b/results/classifier/deepseek-1/output/hypervisor/1952448
deleted file mode 100644
index aa43eff7..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1952448
+++ /dev/null
@@ -1,40 +0,0 @@
-
-qemu 1:6.0+dfsg-2expubuntu2: Fail to build against OpenSSL 3.0
-
-Issue discovered after doing a "No-change rebuild" upload to Jammy while working at the liburing2 migration (LP: #1944037). 
-
-Full build log:
-
-https://launchpadlibrarian.net/570888790/buildlog_ubuntu-jammy-amd64.qemu_1%3A6.0+dfsg-2expubuntu3_BUILDING.txt.gz
-
-Failure mode:
-
-/<<BUILDDIR>>/qemu-6.0+dfsg/roms/skiboot/libstb/create-container.c: In function ‘getPublicKeyRaw’:
-/<<BUILDDIR>>/qemu-6.0+dfsg/roms/skiboot/libstb/create-container.c:85:17: error: ‘EVP_PKEY_get1_EC_KEY’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
-
-Also note that:
-
-cc1: all warnings being treated as errors
-
-Upstream skiboot [1] still uses EVP_PKEY_get1_EC_KEY in master, and don't have an open issue about this. To be filed once we setup a reproducer that builds skiboot "standalone", outside of the qemu source tree.
-
-For the moment we have to relax the severity of that deprecation error, likely appending a -Wno-deprecated-declarations somewhere in d/rules.
-
-
-[1] https://github.com/open-power/skiboot
-
-Messing around with someone elses crypto functions rarely is good ;-)
-So I reported it Upstream at the skiboot project as:
-=> https://github.com/open-power/skiboot/issues/271
-
-This bug was fixed in the package qemu - 1:6.0+dfsg-2expubuntu4
-
----------------
-qemu (1:6.0+dfsg-2expubuntu4) jammy; urgency=medium
-
-  * d/p/lp-1952448-relax-skiboot-gcc-deprecation-errors.patch:
-    add patch to workaround FTBFS when building against OpenSSL 3.0.
-    Thanks to Christian Ehrhardt (LP: #1952448)
-
- -- Paride Legovini <email address hidden>  Fri, 26 Nov 2021 15:47:51 +0100
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/241119 b/results/classifier/deepseek-1/output/hypervisor/241119
deleted file mode 100644
index fdf06c64..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/241119
+++ /dev/null
@@ -1,94 +0,0 @@
-
-usb_add of a Creative ZEN unrecognized in guest
-
-Binary package hint: kvm
-
-This happens when I add my Creative ZEN to a virtual machine running XP. The device is recognised well at first and drivers are installed correctly. But when trying to connect windows crashes with the classic blue screen It complains about something like usbohci.sys, I can't read well because it crashes too fast.
-I have also tried with another virtual machine running Vista, same results.
-Any help would be really appreciated!
-
-I'm using the module kvm-amd with Ubuntu 8.04
-
-The USB device has the following ID: 041e:4157 Creative Technology, Ltd
-
-kvm:
-  Installed: 1:62+dfsg-0ubuntu7
-  Candidate: 1:62+dfsg-0ubuntu7
-  Version table:
- *** 1:62+dfsg-0ubuntu7 0
-        500 http://archive.ubuntu.com hardy/main Packages
-        100 /var/lib/dpkg/status
-
-Hi, thanks for the bug report.
-
-This bug was reported against Hardy's kvm-62.  Unfortunately, kvm-62 is not able to do usb-passthrough properly.
-
-Would it be possible for you to test this against intrepid and/or jaunty?
-
-:-Dustin
-
-If you're running Hardy, could you please test this using the kvm-84 package in this PPA:
- * https://launchpad.net/~ubuntu-virt/+archive/ppa
-
-Does this solve the issue, or is it reproducible?
-
-:-Dustin
-
-
-I'm running Intrepid now, however I tried the package you suggested (kvm-84) but the problem persists.
-
-kvm:
-  Installed: 1:84+dfsg-0ubuntu8~ppa6
-  Candidate: 1:84+dfsg-0ubuntu8~ppa6
-  Version table:
- *** 1:84+dfsg-0ubuntu8~ppa6 0
-        100 /var/lib/dpkg/status
-     1:72+dfsg-1ubuntu6 0
-        500 http://archive.ubuntu.com intrepid/main Packages
-
-The console output when trying to usb_add the device is the following:
-
-husb: open device 1.5
-husb: config #1 need -1
-husb: 1 interfaces claimed for configuration 1
-husb: grabbed usb device 1.5
-usb_linux_update_endp_table: Protocol error
-
-
-I forgot:
-
-Using the new kvm package the virtual machine now doesn't crash with the blue screen anymore. Now it seems like the device is not correctly recognized or initialized
-
-Okay, the problem persists in kvm-84.  I'll mark it as 'Confirmed', and point upstream at the issue.  Thanks.
-
-:-Dustin
-
-@Dustin 
-Did this hit upstream, I looked yesterday and couldn't find it to track it.
-
-To copy this upstream, click "Also affects project", and enter "qemu".
-
-kvm-84 is very old.  Please try to reproduce this against the latest qemu git or at least 0.12.4.
-
-Hi. I have a similar problem, with a simple JetFlash usb drive.
-
-After adding it with usb_add, "info usb" shows nothing and I start getting the following message in the console:
-husb: config #1 need -1
-husb: 1 interfaces claimed for configuration 1
-husb: grabbed usb device 1.3
-usb_linux_update_endp_table: Protocol error
-
-This is under Maverick using qemu-kvm 0.12.5+noroms-0ubuntu7
-
-The same operation works fine in the same pc under my gentoo system, currently running qemu-kvm-0.13.0, but it has been working now for a year, without ever giving me problems.
-
-Hi,
-
-is this still an issue under natty or oneiric?
-
-Hi, unfortunately my Creative ZEN (for which I initially issued the bug) broke, so I am not able to verify if it is an issue anymore, I'm sorry.
-
-[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.]
-
-Closing this bug since the hardware is not available anymore (according to comment #11).
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/608107 b/results/classifier/deepseek-1/output/hypervisor/608107
deleted file mode 100644
index b558d5ce..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/608107
+++ /dev/null
@@ -1,39 +0,0 @@
-
-ppc fails to clear MSR_POW when incurring exception
-
-QEMU VERSION: 0.12.4
-
-According to FreeScale's 'Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 fails to do so.
-Resetting the bit is necessary in order to bring the processor out of power-management since otherwise it goes to sleep right away in the exception handler, i.e., it is impossible to leave PM-mode.
-
-
-
-Thomas Monjalon wrote:
-> From: till <email address hidden>
->
-> According to FreeScale's 'Programming Environments Manual for 32-bit
-> Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005],
-> section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4
-> fails to do so.
-> Resetting the bit is necessary in order to bring the processor out of power
-> management since otherwise it goes to sleep right away in the exception
-> handler, i.e., it is impossible to leave PM-mode.
->   
-
-This doesn't look right. POW shouldn't even get stored in SRR1. Could
-you please redo the patch and make sure that mtmsr masks out MSR_POW?
-
-
-Alex
-
-
-I'm afraid I don't understand. My the problem and fix doesn't address mtmsr at all.
-It just makes sure MSR_POW is cleared in MSR when an exception occurs.
-
-Do you mean MSR_POW should masked from MSR before saving it to SRR1?
-That's already taken care of (target-ppc/helper.c:2074 [qemu-0.12.4]).
-
-As far as I can see, this problem has been fixed by this commit here:
-http://git.qemu.org/?p=qemu.git;a=commitdiff;h=41557447d30eeb944e4
-... so I'm setting the status to "Fix released" now.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/643430 b/results/classifier/deepseek-1/output/hypervisor/643430
deleted file mode 100644
index 009707d2..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/643430
+++ /dev/null
@@ -1,38 +0,0 @@
-
-system_powerdown NOT working in qemu-kvm with KVM enabled for FreeBSD guests
-
-system_powerdown stops working in qemu-kvm for FreeBSD guests if KVM is enabled.
-
-How to reproduce:
-
-1. qemu -cdrom ~/.VirtualBox/libvirt/FreeBSD-8.1-RELEASE-i386-bootonly.iso
-2. Enter system_powerdown in the qemu console
-3. Nothing happens.
-
-Adding --no-kvm option makes system_powerdown work:
-
-1. qemu --no-kvm -cdrom ~/.VirtualBox/libvirt/FreeBSD-8.1-RELEASE-i386-bootonly.iso
-2. system_powerdown
-3. FreeBSD installer shows the shutdown dialog as expected
-
-Tested on FreeBSD 6.4, 7.2, and 8.0 with qemu-kvm 0.12.5 and older versions.
-
-The subject should be: system_powerdown is NOT working - can someone correct this please?
-
-I have the same issue with FreeBSD 8.1-RELEASE (i386 and x86_64) on qemu-kvm 0.12.5 (Fedora 13)
-
-system_powerdown works properly for Linux and Windows 2008 guests, but not for FreeBSD The ACPI power button event is not received by the FreeBSD guest.
-
-I found this (unconfirmed) status report:
-http://www.spinics.net/lists/kvm/msg40064.html
-
-So it seems to be a regression...
-
-
-
-This is fixed upstream (in seabios actually) by commit 6d5a2172f2b76900572107868ec080400c4f615d -- see http://git.linuxtogo.org/?p=kevin/seabios.git;a=commit;h=6d5a2172f2b76900572107868ec080400c4f615d .  I added this patch to Debian releases of qemu-kvm, both for squeeze and experimental.
-
-The updated bios.bin works fine for me, thanks.
-
-Marking this now as "Fix released" according to comment #3
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/692570 b/results/classifier/deepseek-1/output/hypervisor/692570
deleted file mode 100644
index 0a443f54..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/692570
+++ /dev/null
@@ -1,112 +0,0 @@
-
-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.
-
-Since there hasn't been an answer to this within the last years, it looks like nobody here knows about Proxmox problems. So let's close this ticket...
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/720657 b/results/classifier/deepseek-1/output/hypervisor/720657
deleted file mode 100644
index 6fb9ae8a..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/720657
+++ /dev/null
@@ -1,30 +0,0 @@
-
-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).
-
-Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/928676 b/results/classifier/deepseek-1/output/hypervisor/928676
deleted file mode 100644
index 1667ebbb..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/928676
+++ /dev/null
@@ -1,43 +0,0 @@
-
-QEMU does not support Westmere (Intel Xeon) CPU model
-
-Setting the CPU model to Westmere (Intel Xeon server CPU) is not possible.
-
-libvirt uses 'core2duo' as fallback:
-https://bugzilla.redhat.com/show_bug.cgi?id=708927
-
-
-$ qemu -cpu ?
-x86           [n270]
-x86         [athlon]
-x86       [pentium3]
-x86       [pentium2]
-x86        [pentium]
-x86            [486]
-x86        [coreduo]
-x86          [kvm32]
-x86         [qemu32]
-x86          [kvm64]
-x86       [core2duo]
-x86         [phenom]
-x86         [qemu64]
-
-$ qemu --version
-QEMU emulator version 1.0 (Debian 1.0+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard
-
-An application test with high cpu load gives the timing statistics give:
-                                              
-
-                                           bare metal                       virtual                           percent
-
-X4560 cpu                            50m28s                          54m0s                          107%
-
-X5690 (westermere)         29m20s                          38m0s                         134%
-
-
-
-Westmere seems to be available in the latest version of QEMU:
-$ qemu-system-x86_64 -cpu ? | grep Westmere
-x86         Westmere  Westmere E56xx/L56xx/X56xx (Nehalem-C)
-==> Setting status to "Fix released" now.
-
diff --git a/results/classifier/deepseek-1/output/hypervisor/992067 b/results/classifier/deepseek-1/output/hypervisor/992067
deleted file mode 100644
index aec5cef0..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/992067
+++ /dev/null
@@ -1,34 +0,0 @@
-
-Windows 2008R2 very slow cold boot when >4GB memory
-
-I've been having a consistent problem booting 2008R2 guests with 4096MB of RAM or greater. On the initial boot the KVM process starts out with a ~200MB memory allocation and will use 100% of all CPU allocated to it. The RES memory of the KVM process slowly rises by around 200mb every few minutes until it reaches it's memory allocation (several hours in some cases). Whilst this is happening the guest will usually blue screen with the message of -
-
-A clock interrupt was not received on a secondary processor within the allocated time interval
-
-If I let the KVM process continue to run it will eventually allocate the required memory the guest will run at full speed, usually restarting after the blue screen and booting into startup repair. From here you can restart it and it will boot perfectly. Once booted the guest has no performance issues at all. 
-
-I've tried everything I could think of. Removing PAE, playing with huge pages, different kernels, different userspaces, different systems, different backing file systems, different processor feature set, with or without Virtio etc. My best theory is that the problem is caused by Windows 2008 zeroing out all the memory on boot and something is causing this to be held up or slowed to a crawl. The hosts always have memory free to boot the guest and are not using swap at all. 
-
-Nothing so far has solved the issue. A few observations I've made about the issue are - 
-Large memory 2008R2 guests seem to boot fine (or with a small delay) when they are the first to boot on the host after a reboot
-Sometimes dropping the disk cache (echo 1 > /proc/sys/vm/drop_caches) will cause them to boot faster
-
-
-The hosts I've tried are -
-All Nehalem based (5540, 5620 and 5660)
-Host ram of 48GB, 96GB and 192GB
-Storage on NFS, Gluster and local (ext4, xfs and zfs)
-QED, QCOW and RAW formats
-Scientific Linux 6.1 with the standard kernel 2.6.32, 2.6.38 and 3.3.1
-KVM userspaces 0.12, 0.14 and (currently) 0.15.1
-
-This should be resolved by using Hyper-V relaxed timers which is in the latest development version of QEMU.  You would need to add -cpu host,+hv_relaxed to the command line to verify this.
-
-Thanks for the quick reply,
-
-I pulled the latest version from Git and on first attempt it said the hv_relaxed feature was not present. I checked the source and the 'hv_relaxed' feature was not included in a 'feature_name' array so the flag was being discarded before it could be enabled. 
-
-Once added in to the 'feature_name' array it was enabled but the VM crashes on boot with a blue screen and the error message "Phase0_exception" followed by a reboot.
-
-Triaging old bug tickets... QEMU 0.12/0.14/0.15 is pretty outdated nowadays. Can you still reproduce this behavior with the latest version of QEMU? If not, I think we should close this bug...
-
author	Christian Krinitsin <mail@krinitsin.com>	2025-07-03 19:39:53 +0200
committer	Christian Krinitsin <mail@krinitsin.com>	2025-07-03 19:39:53 +0200
commit	dee4dcba78baf712cab403d47d9db319ab7f95d6 (patch)
tree	418478faf06786701a56268672f73d6b0b4eb239 /results/classifier/deepseek-1/output/hypervisor
parent	4d9e26c0333abd39bdbd039dcdb30ed429c475ba (diff)
download	emulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.tar.gz emulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.zip