4 files changed, 556 insertions, 0 deletions
diff --git a/results/classifier/111/boot/1435101 b/results/classifier/111/boot/1435101
new file mode 100644
index 000000000..8a75f10df
--- /dev/null
+++ b/results/classifier/111/boot/1435101
@@ -0,0 +1,39 @@
+boot: 0.168
+other: 0.156
+device: 0.112
+semantic: 0.109
+vnc: 0.073
+files: 0.070
+graphic: 0.064
+performance: 0.061
+PID: 0.050
+socket: 0.043
+debug: 0.037
+permissions: 0.030
+network: 0.020
+KVM: 0.007
+boot: 0.816
+debug: 0.048
+files: 0.023
+other: 0.022
+network: 0.020
+performance: 0.017
+PID: 0.012
+semantic: 0.010
+socket: 0.010
+device: 0.010
+vnc: 0.004
+permissions: 0.004
+graphic: 0.004
+KVM: 0.002
+
+Windows, QEMU 2.2.50 fails to boot XP CD
+
+Running XP Pro SP3 host 32bit.  When I launch qemu booting from CD, it fails to complete load, getting stuck at "Setup is starting Windows". It does not proceed past. I tried to disable floppy but still no go. Download older version 1.5.1-win32, 0.9.1, same problem. 
+qemu-system-i386w.exe -cdrom "d:\XP.ISO" -hda d:\xp.img -boot d 
+with -global isa-fdc.driveA=c or -no-fd-bootchk switches but no go. I see others have run into this problem as well but no real solutions. Some folks says turning off floppy works and I tried.
+
+Triaging 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/111/boot/1591724 b/results/classifier/111/boot/1591724
new file mode 100644
index 000000000..4fc194029
--- /dev/null
+++ b/results/classifier/111/boot/1591724
@@ -0,0 +1,83 @@
+boot: 0.095
+other: 0.090
+socket: 0.087
+device: 0.085
+permissions: 0.083
+PID: 0.078
+graphic: 0.074
+files: 0.069
+vnc: 0.065
+semantic: 0.064
+network: 0.060
+debug: 0.057
+performance: 0.052
+KVM: 0.041
+boot: 0.310
+debug: 0.125
+files: 0.112
+network: 0.063
+KVM: 0.057
+device: 0.050
+socket: 0.050
+PID: 0.045
+other: 0.042
+semantic: 0.038
+vnc: 0.030
+graphic: 0.030
+performance: 0.028
+permissions: 0.020
+
+Windows 7 installation DVD can't boot in qemu 2.6.0/OVMF
+
+With Qemu 2.5.50 (compiled from git some time ago) I can boot Windows 7 x64 installation DVD as follows:
+~/code/qemu-v2/bin/slic-v2/native/x86_64-softmmu/qemu-system-x86_64 \
+    -machine type=pc,accel=kvm \
+    -enable-kvm \
+    -cpu host \
+    -m 2048 \
+    -vga cirrus \
+    -boot d \
+    -drive if=pflash,file=/vms/ovmf_x64_firstrun.bin,format=raw \
+    -cdrom /vms/win7_sp1.iso \
+    -monitor stdio
+
+This bug suggests different vga options https://bugs.launchpad.net/qemu/+bug/1581936. Here's the behaviours I'm getting with 2.6.0:
+
+std - "Starting Windows" with wavering flag hangs indefinitely
+cirrus - at "Starting Windows" wasps of light freeze before assembling into a flag
+qxl - "Starting Windows" with wavering flag hangs indefinitely
+virtio - "Starting Windows" with wavering flag hangs indefinitely
+
+supposed to be fixed by <http://git.qemu.org/?p=qemu.git;a=commit;h=94ef4f337fb614f18b765a8e0e878a4c23cdedcd>, please confirm
+
+Running on latest git code a93c1bdf0bd4689287094ddb2aae3dc907da3535, DVD loads installation screen on everything except cirrus (same symptom). I don't really need cirrus, but I can test patches if you want.
+
+The following combination:
+
+- OVMF without the SeaBIOS CSM ("pure EFI" in Gerd's RPMs)
+- Cirrus video card
+- Windows 7 installer in the guest
+
+has never been supported. The VBE Shim in OVMF works on stdvga and QXL only. This is documented; please refer to OvmfPkg/README, section "UEFI Windows 7 & Windows 2008 Server".
+
+According to your results, stuff works on latest QEMU, in all configurations that are expected to be functional. Gerd CC'd <email address hidden> on his patch referenced above, so I guess it will be part of 2.6.1, whenever it is released. I'm closing this with fix committed. Thanks.
+
+The same thing. Qemu 2.5 and no possibility to install Windows 7 on OVMF, no possibility to install Windows 7 with QXL video. This is something terrible. Several hours I'm trying to install it but only on BIOS and with Cirrus video. What Qemu version will be fixed?
+
+@Gannet I've built latest qemu from git just to get through installation, after that everything runs fine on 2.6.0. It's easy enough http://wiki.qemu.org/Hosts/Linux#Simple_build_and_test
+
+Fails on my machine, even with the HEAD of master as of today (5d3217340adcb6c4f0e4af5d2b865331eb2ff63d).
+
+Simplest configuration:
+
+    cp $MY_BIOS $MY_BIOS_TMP; ./qemu-system-x86_64 \
+      -drive if=pflash,format=raw,readonly,file=$MY_BIOS \
+      -drive if=pflash,format=raw,file=$MY_BIOS_TMP \
+      -enable-kvm \
+      -m 3072 \
+      -cpu host,kvm=off -smp 4,sockets=1,cores=4 \
+      -cdrom $MY_WINDOWS_CD
+    ;
+
+Hangs on "Starting Windows".
+
diff --git a/results/classifier/111/boot/1879590 b/results/classifier/111/boot/1879590
new file mode 100644
index 000000000..8c44edb62
--- /dev/null
+++ b/results/classifier/111/boot/1879590
@@ -0,0 +1,102 @@
+boot: 0.151
+other: 0.127
+network: 0.126
+PID: 0.081
+device: 0.073
+semantic: 0.067
+graphic: 0.063
+files: 0.063
+socket: 0.054
+permissions: 0.053
+debug: 0.048
+performance: 0.042
+vnc: 0.034
+KVM: 0.020
+boot: 0.468
+debug: 0.179
+other: 0.050
+device: 0.049
+PID: 0.047
+files: 0.041
+network: 0.037
+socket: 0.030
+semantic: 0.025
+performance: 0.020
+graphic: 0.019
+permissions: 0.015
+vnc: 0.012
+KVM: 0.008
+
+Using qemu-system-sparc64 no network interface seems to exist
+
+Using boot command:
+
+qemu-system-sparc64 -M niagara -L /home/chrisp/sparc/S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=/home/chrisp/sparc/S10image/disk.s10hw2
+
+After I log into solaris system I see no network devices other than the loopback device.
+All the docs I can see suggest it should come up with a default network device that allows communication via the hosts network. Host is ubuntu 64bit.  
+
+root@giant:/home/chrisp/sparc# qemu-system-sparc64 -version
+QEMU emulator version 5.0.0
+Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
+
+
+dladm show-link
+ifconfig -a
+
+
+
+ok boot
+Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
+FCode UFS Reader 1.12 00/07/17 15:48:16.
+Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
+Loading: /platform/sun4v/ufsboot
+SunOS Release 5.10 Version Generic_118822-23 64-bit
+Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
+Use is subject to license terms.
+Hostname: unknown
+
+unknown console login: root
+Last login: Wed Feb  8 09:01:28 on console
+Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
+# dladm show-link
+# ifconfig -a
+lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
+        inet 127.0.0.1 netmask ff000000
+
+Unfortunately it's been a while and no one has added the proper support to qemu yet, see comments at:
+http://tyom.blogspot.com/2016/10/qemu-sun4vniagara-target-went-public.html
+Apparently the niagara PCI adapter has to be implemented and the firmware recompiled to enable it. 
+
+
+
+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 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.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/boot/51610399 b/results/classifier/111/boot/51610399
new file mode 100644
index 000000000..98d0e8a3e
--- /dev/null
+++ b/results/classifier/111/boot/51610399
@@ -0,0 +1,332 @@
+boot: 0.087
+permissions: 0.084
+other: 0.082
+device: 0.079
+debug: 0.078
+semantic: 0.074
+graphic: 0.072
+files: 0.070
+KVM: 0.068
+performance: 0.066
+PID: 0.065
+vnc: 0.062
+socket: 0.061
+network: 0.053
+boot: 0.492
+KVM: 0.291
+debug: 0.089
+PID: 0.029
+device: 0.023
+socket: 0.020
+files: 0.016
+performance: 0.008
+semantic: 0.008
+other: 0.007
+network: 0.006
+graphic: 0.004
+permissions: 0.004
+vnc: 0.002
+
+[BUG][powerpc] KVM Guest Boot Failure – Hangs at "Booting Linux via __start()”
+
+Bug Description:
+Encountering a boot failure when launching a KVM guest with
+qemu-system-ppc64. The guest hangs at boot, and the QEMU monitor
+crashes.
+Reproduction Steps:
+# qemu-system-ppc64 --version
+QEMU emulator version 9.2.50 (v9.2.0-2799-g0462a32b4f)
+Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
+# /usr/bin/qemu-system-ppc64 -name avocado-vt-vm1 -machine
+pseries,accel=kvm \
+-m 32768 -smp 32,sockets=1,cores=32,threads=1 -nographic \
+  -device virtio-scsi-pci,id=scsi \
+-drive
+file=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel-ppc64le.qcow2,if=none,id=drive0,format=qcow2
+\
+-device scsi-hd,drive=drive0,bus=scsi.0 \
+  -netdev bridge,id=net0,br=virbr0 \
+  -device virtio-net-pci,netdev=net0 \
+  -serial pty \
+  -device virtio-balloon-pci \
+  -cpu host
+QEMU 9.2.50 monitor - type 'help' for more information
+char device redirected to /dev/pts/2 (label serial0)
+(qemu)
+(qemu) qemu-system-ppc64: warning: kernel_irqchip allowed but
+unavailable: IRQ_XIVE capability must be present for KVM
+Falling back to kernel-irqchip=off
+** Qemu Hang
+
+(In another ssh session)
+# screen /dev/pts/2
+Preparing to boot Linux version 6.10.4-200.fc40.ppc64le
+(mockbuild@c23cc4e677614c34bb22d54eeea4dc1f) (gcc (GCC) 14.2.1 20240801
+(Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP Sun Aug 11
+15:20:17 UTC 2024
+Detected machine type: 0000000000000101
+command line:
+BOOT_IMAGE=(ieee1275/disk,msdos2)/vmlinuz-6.10.4-200.fc40.ppc64le
+root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root crashkernel=1024M
+Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
+Calling ibm,client-architecture-support... done
+memory layout at init:
+  memory_limit : 0000000000000000 (16 MB aligned)
+  alloc_bottom : 0000000008200000
+  alloc_top    : 0000000030000000
+  alloc_top_hi : 0000000800000000
+  rmo_top      : 0000000030000000
+  ram_top      : 0000000800000000
+instantiating rtas at 0x000000002fff0000... done
+prom_hold_cpus: skipped
+copying OF device tree...
+Building dt strings...
+Building dt structure...
+Device tree strings 0x0000000008210000 -> 0x0000000008210bd0
+Device tree struct  0x0000000008220000 -> 0x0000000008230000
+Quiescing Open Firmware ...
+Booting Linux via __start() @ 0x0000000000440000 ...
+** Guest Console Hang
+
+
+Git Bisect:
+Performing git bisect points to the following patch:
+# git bisect bad
+e8291ec16da80566c121c68d9112be458954d90b is the first bad commit
+commit e8291ec16da80566c121c68d9112be458954d90b (HEAD)
+Author: Nicholas Piggin <npiggin@gmail.com>
+Date:   Thu Dec 19 13:40:31 2024 +1000
+
+    target/ppc: fix timebase register reset state
+(H)DEC and PURR get reset before icount does, which causes them to
+be
+skewed and not match the init state. This can cause replay to not
+match the recorded trace exactly. For DEC and HDEC this is usually
+not
+noticable since they tend to get programmed before affecting the
+    target machine. PURR has been observed to cause replay bugs when
+    running Linux.
+
+    Fix this by resetting using a time of 0.
+
+    Message-ID: <20241219034035.1826173-2-npiggin@gmail.com>
+    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+
+ hw/ppc/ppc.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+
+Reverting the patch helps boot the guest.
+Thanks,
+Misbah Anjum N
+
+Thanks for the report.
+
+Tricky problem. A secondary CPU is hanging before it is started by the
+primary via rtas call.
+
+That secondary keeps calling kvm_cpu_exec(), which keeps exiting out
+early with EXCP_HLT because kvm_arch_process_async_events() returns
+true because that cpu has ->halted=1. That just goes around he run
+loop because there is an interrupt pending (DEC).
+
+So it never runs. It also never releases the BQL, and another CPU,
+the primary which is actually supposed to be running, is stuck in
+spapr_set_all_lpcrs() in run_on_cpu() waiting for the BQL.
+
+This patch just exposes the bug I think, by causing the interrupt.
+although I'm not quite sure why it's okay previously (-ve decrementer
+values should be causing a timer exception too). The timer exception
+should not be taken as an interrupt by those secondary CPUs, and it
+doesn't because it is masked, until set_all_lpcrs sets an LPCR value
+that enables powersave wakeup on decrementer interrupt.
+
+The start_powered_off sate just sets ->halted, which makes it look
+like a powersaving state. Logically I think it's not the same thing
+as far as spapr goes. I don't know why start_powered_off only sets
+->halted, and not ->stop/stopped as well.
+
+Not sure how best to solve it cleanly. I'll send a revert if I can't
+get something working soon.
+
+Thanks,
+Nick
+
+On Tue Mar 18, 2025 at 7:09 AM AEST, misanjum wrote:
+>
+Bug Description:
+>
+Encountering a boot failure when launching a KVM guest with
+>
+qemu-system-ppc64. The guest hangs at boot, and the QEMU monitor
+>
+crashes.
+>
+>
+>
+Reproduction Steps:
+>
+# qemu-system-ppc64 --version
+>
+QEMU emulator version 9.2.50 (v9.2.0-2799-g0462a32b4f)
+>
+Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
+>
+>
+# /usr/bin/qemu-system-ppc64 -name avocado-vt-vm1 -machine
+>
+pseries,accel=kvm \
+>
+-m 32768 -smp 32,sockets=1,cores=32,threads=1 -nographic \
+>
+-device virtio-scsi-pci,id=scsi \
+>
+-drive
+>
+file=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel-ppc64le.qcow2,if=none,id=drive0,format=qcow2
+>
+>
+\
+>
+-device scsi-hd,drive=drive0,bus=scsi.0 \
+>
+-netdev bridge,id=net0,br=virbr0 \
+>
+-device virtio-net-pci,netdev=net0 \
+>
+-serial pty \
+>
+-device virtio-balloon-pci \
+>
+-cpu host
+>
+QEMU 9.2.50 monitor - type 'help' for more information
+>
+char device redirected to /dev/pts/2 (label serial0)
+>
+(qemu)
+>
+(qemu) qemu-system-ppc64: warning: kernel_irqchip allowed but
+>
+unavailable: IRQ_XIVE capability must be present for KVM
+>
+Falling back to kernel-irqchip=off
+>
+** Qemu Hang
+>
+>
+(In another ssh session)
+>
+# screen /dev/pts/2
+>
+Preparing to boot Linux version 6.10.4-200.fc40.ppc64le
+>
+(mockbuild@c23cc4e677614c34bb22d54eeea4dc1f) (gcc (GCC) 14.2.1 20240801
+>
+(Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP Sun Aug 11
+>
+15:20:17 UTC 2024
+>
+Detected machine type: 0000000000000101
+>
+command line:
+>
+BOOT_IMAGE=(ieee1275/disk,msdos2)/vmlinuz-6.10.4-200.fc40.ppc64le
+>
+root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root crashkernel=1024M
+>
+Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
+>
+Calling ibm,client-architecture-support... done
+>
+memory layout at init:
+>
+memory_limit : 0000000000000000 (16 MB aligned)
+>
+alloc_bottom : 0000000008200000
+>
+alloc_top    : 0000000030000000
+>
+alloc_top_hi : 0000000800000000
+>
+rmo_top      : 0000000030000000
+>
+ram_top      : 0000000800000000
+>
+instantiating rtas at 0x000000002fff0000... done
+>
+prom_hold_cpus: skipped
+>
+copying OF device tree...
+>
+Building dt strings...
+>
+Building dt structure...
+>
+Device tree strings 0x0000000008210000 -> 0x0000000008210bd0
+>
+Device tree struct  0x0000000008220000 -> 0x0000000008230000
+>
+Quiescing Open Firmware ...
+>
+Booting Linux via __start() @ 0x0000000000440000 ...
+>
+** Guest Console Hang
+>
+>
+>
+Git Bisect:
+>
+Performing git bisect points to the following patch:
+>
+# git bisect bad
+>
+e8291ec16da80566c121c68d9112be458954d90b is the first bad commit
+>
+commit e8291ec16da80566c121c68d9112be458954d90b (HEAD)
+>
+Author: Nicholas Piggin <npiggin@gmail.com>
+>
+Date:   Thu Dec 19 13:40:31 2024 +1000
+>
+>
+target/ppc: fix timebase register reset state
+>
+>
+(H)DEC and PURR get reset before icount does, which causes them to
+>
+be
+>
+skewed and not match the init state. This can cause replay to not
+>
+match the recorded trace exactly. For DEC and HDEC this is usually
+>
+not
+>
+noticable since they tend to get programmed before affecting the
+>
+target machine. PURR has been observed to cause replay bugs when
+>
+running Linux.
+>
+>
+Fix this by resetting using a time of 0.
+>
+>
+Message-ID: <20241219034035.1826173-2-npiggin@gmail.com>
+>
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+>
+>
+hw/ppc/ppc.c | 11 ++++++++---
+>
+1 file changed, 8 insertions(+), 3 deletions(-)
+>
+>
+>
+Reverting the patch helps boot the guest.
+>
+Thanks,
+>
+Misbah Anjum N
+