summary refs log tree commit diff stats
path: root/results/classifier/108/other/222
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/22216
-rw-r--r--results/classifier/108/other/222116
-rw-r--r--results/classifier/108/other/2221921053
-rw-r--r--results/classifier/108/other/222216
-rw-r--r--results/classifier/108/other/2224220
-rw-r--r--results/classifier/108/other/222526
-rw-r--r--results/classifier/108/other/222671
-rw-r--r--results/classifier/108/other/222823
-rw-r--r--results/classifier/108/other/222920
9 files changed, 461 insertions, 0 deletions
diff --git a/results/classifier/108/other/222 b/results/classifier/108/other/222
new file mode 100644
index 000000000..d365cecd9
--- /dev/null
+++ b/results/classifier/108/other/222
@@ -0,0 +1,16 @@
+PID: 0.792
+performance: 0.634
+device: 0.565
+semantic: 0.510
+graphic: 0.501
+other: 0.441
+network: 0.284
+KVM: 0.169
+debug: 0.134
+socket: 0.133
+boot: 0.126
+vnc: 0.107
+permissions: 0.093
+files: 0.032
+
+Reading /proc/self/task/<pid>/maps is not remapped to the target
diff --git a/results/classifier/108/other/2221 b/results/classifier/108/other/2221
new file mode 100644
index 000000000..e05c34231
--- /dev/null
+++ b/results/classifier/108/other/2221
@@ -0,0 +1,16 @@
+performance: 0.786
+device: 0.647
+graphic: 0.455
+network: 0.435
+boot: 0.206
+semantic: 0.121
+vnc: 0.062
+files: 0.044
+permissions: 0.019
+socket: 0.015
+debug: 0.013
+other: 0.009
+PID: 0.009
+KVM: 0.006
+
+CI timeouts on 'gcov' job: test-bufferiszero, test-crypto-tlscredsx509
diff --git a/results/classifier/108/other/22219210 b/results/classifier/108/other/22219210
new file mode 100644
index 000000000..62e24e9f0
--- /dev/null
+++ b/results/classifier/108/other/22219210
@@ -0,0 +1,53 @@
+graphic: 0.701
+performance: 0.498
+device: 0.489
+semantic: 0.387
+other: 0.345
+network: 0.323
+socket: 0.244
+debug: 0.225
+PID: 0.214
+vnc: 0.204
+files: 0.202
+permissions: 0.141
+KVM: 0.099
+boot: 0.070
+
+[BUG][CPU hot-plug]CPU hot-plugs cause the qemu process to coredump
+
+Hello,Recently, when I was developing CPU hot-plugs under the loongarch
+architecture,
+I found that there was a problem with qemu cpu hot-plugs under x86
+architecture,
+which caused the qemu process coredump when repeatedly inserting and
+unplugging
+the CPU when the TCG was accelerated.
+
+
+The specific operation process is as follows:
+
+1.Use the following command to start the virtual machine
+
+qemu-system-x86_64 \
+-machine q35  \
+-cpu Broadwell-IBRS \
+-smp 1,maxcpus=4,sockets=4,cores=1,threads=1 \
+-m 4G \
+-drive file=~/anolis-8.8.qcow2  \
+-serial stdio   \
+-monitor telnet:localhost:4498,server,nowait
+
+
+2.Enter QEMU Monitor via telnet for repeated CPU insertion and unplugging
+
+telnet 127.0.0.1 4498
+(qemu) device_add
+Broadwell-IBRS-x86_64-cpu,socket-id=1,core-id=0,thread-id=0,id=cpu1
+(qemu) device_del cpu1
+(qemu) device_add
+Broadwell-IBRS-x86_64-cpu,socket-id=1,core-id=0,thread-id=0,id=cpu1
+3.You will notice that the QEMU process has a coredump
+
+# malloc(): unsorted double linked list corrupted
+Aborted (core dumped)
+
diff --git a/results/classifier/108/other/2222 b/results/classifier/108/other/2222
new file mode 100644
index 000000000..866ff541f
--- /dev/null
+++ b/results/classifier/108/other/2222
@@ -0,0 +1,16 @@
+device: 0.915
+performance: 0.663
+network: 0.585
+graphic: 0.515
+files: 0.478
+debug: 0.263
+semantic: 0.253
+permissions: 0.205
+other: 0.121
+boot: 0.114
+PID: 0.081
+socket: 0.064
+vnc: 0.015
+KVM: 0.003
+
+elf2dmp has endianness bugs
diff --git a/results/classifier/108/other/2224 b/results/classifier/108/other/2224
new file mode 100644
index 000000000..91d6aa459
--- /dev/null
+++ b/results/classifier/108/other/2224
@@ -0,0 +1,220 @@
+other: 0.889
+permissions: 0.855
+boot: 0.840
+graphic: 0.825
+vnc: 0.817
+semantic: 0.813
+device: 0.800
+socket: 0.799
+performance: 0.793
+PID: 0.791
+debug: 0.790
+files: 0.782
+network: 0.780
+KVM: 0.715
+
+OpenBSD 7.4+ does not boot on sbsa-ref with Neoverse-V1/N2 or max cpu core
+Description of problem:
+System boots and then hangs:
+
+```
+disks: sd0*
+>> OpenBSD/arm64 BOOTAA64 1.18
+boot>
+cannot open sd0a:/etc/random.seed: No such file or directory
+booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1
+3d5cf8
+FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+        The Regents of the University of California.  All rights reserved.
+Copyright (c) 1995-2023 OpenBSD. All rights reserved.  https://www.OpenBSD.org
+
+OpenBSD 7.4 (RAMDISK) #2131: Sun Oct  8 13:35:40 MDT 2023
+    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
+real mem  = 1066156032 (1016MB)
+avail mem = 996659200 (950MB)
+random: boothowto does not indicate good seed
+mainbus0 at root: ACPI
+psci0 at mainbus0: PSCI 1.1, SMCCC 1.4
+efi0 at mainbus0: UEFI 2.7
+efi0: EFI Development Kit II / SbsaQemu rev 0x10000
+smbios0 at efi0: SMBIOS 3.4.0
+smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024
+smbios0: QEMU QEMU SBSA-REF Machine
+cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3
+cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache
+cpu0: 0KB 64b/line 8-way L2 cache
+cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR
+agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller"
+agintcmsi0 at agintc0
+agtimer0 at mainbus0: 62500 kHz
+acpi0 at mainbus0: ACPI 6.0
+acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+acpimcfg0 at acpi0
+acpimcfg0: addr 0xf0000000, bus 0-255
+acpiiort0 at acpi0
+pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33
+pluart0: console
+ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0
+ahci0: port 0: 1.5Gb/s
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_
+sd0: 43MB, 512 bytes/sector, 88064 sectors, thin
+xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0
+usb0 at xhci0: USB revision 3.0
+uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
+acpipci0 at acpi0 PCI0
+pci0 at acpipci0
+0:1:0: rom address conflict 0xfffc0000/0x40000
+0:2:0: rom address conflict 0xffff8000/0x8000
+"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
+em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56
+"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+simplefb0 at mainbus0: 1280x800, 32bpp
+wsdisplay0 at simplefb0 mux 1
+wsdisplay0: screen 0 added (std, vt100 emulation)
+```
+
+If I use Neoverse-N1 (sbsa-ref default core type) then it boots into installer:
+
+```
+disks: sd0*
+>> OpenBSD/arm64 BOOTAA64 1.18
+boot>
+cannot open sd0a:/etc/random.seed: No such file or directory
+booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1
+3d5cf8
+FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+        The Regents of the University of California.  All rights reserved.
+Copyright (c) 1995-2023 OpenBSD. All rights reserved.  https://www.OpenBSD.org
+
+OpenBSD 7.4 (RAMDISK) #2131: Sun Oct  8 13:35:40 MDT 2023
+    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
+real mem  = 1066156032 (1016MB)
+avail mem = 996659200 (950MB)
+random: boothowto does not indicate good seed
+mainbus0 at root: ACPI
+psci0 at mainbus0: PSCI 1.1, SMCCC 1.4
+efi0 at mainbus0: UEFI 2.7
+efi0: EFI Development Kit II / SbsaQemu rev 0x10000
+smbios0 at efi0: SMBIOS 3.4.0
+smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024
+smbios0: QEMU QEMU SBSA-REF Machine
+cpu0 at mainbus0 mpidr 0: ARM Neoverse N1 r4p1
+cpu0: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache
+cpu0: 1024KB 64b/line 8-way L2 cache
+cpu0: DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SBSS+MSR
+agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller"
+agintcmsi0 at agintc0
+agtimer0 at mainbus0: 62500 kHz
+acpi0 at mainbus0: ACPI 6.0
+acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+acpimcfg0 at acpi0
+acpimcfg0: addr 0xf0000000, bus 0-255
+acpiiort0 at acpi0
+pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33
+pluart0: console
+ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0
+ahci0: port 0: 1.5Gb/s
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_
+sd0: 43MB, 512 bytes/sector, 88064 sectors, thin
+xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0
+usb0 at xhci0: USB revision 3.0
+uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
+acpipci0 at acpi0 PCI0
+pci0 at acpipci0
+0:1:0: rom address conflict 0xfffc0000/0x40000
+0:2:0: rom address conflict 0xffff8000/0x8000
+"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
+em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56
+"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+simplefb0 at mainbus0: 1280x800, 32bpp
+wsdisplay0 at simplefb0 mux 1
+wsdisplay0: screen 0 added (std, vt100 emulation)
+softraid0 at root
+scsibus1 at softraid0: 256 targets
+root on rd0a swap on rd0b dump on rd0b
+WARNING: CHECK AND RESET THE DATE!
+erase ^?, werase ^W, kill ^U, intr ^C, status ^T
+
+Welcome to the OpenBSD/arm64 7.4 installation program.
+(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?
+```
+Steps to reproduce:
+1. download OpenBSD 7.4 image: https://cdn.openbsd.org/pub/OpenBSD/7.4/arm64/miniroot74.img
+2. download sbsa-ref firmware files from https://artifacts.codelinaro.org/ui/native/linaro-419-sbsa-ref/20240313-116475/edk2/ and decompress them
+3. start qemu-system-aarch64 as shown above (adapt paths if needed)
+4. watch console serial output
+Additional information:
+I am going to discuss this on OpenBSD mailing list. Will point to this bug.
+
+OpenBSD 7.5-current snapshot works on Neoverse-N1 and fails on Neoverse-V1/N2/max:
+
+```
+disks: sd0*
+>> OpenBSD/arm64 BOOTAA64 1.18
+boot>
+cannot open sd0a:/etc/random.seed: No such file or directory
+booting sd0a:/bsd: 3015576+1213504+12712936+634144 [269381+91+701664+287051]=0x1
+3edee0
+FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+        The Regents of the University of California.  All rights reserved.
+Copyright (c) 1995-2024 OpenBSD. All rights reserved.  https://www.OpenBSD.org
+
+OpenBSD 7.5 (RAMDISK) #121: Thu Mar 14 03:28:46 MDT 2024
+    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
+real mem  = 1066147840 (1016MB)
+avail mem = 992886784 (946MB)
+random: boothowto does not indicate good seed
+mainbus0 at root: ACPI
+psci0 at mainbus0: PSCI 1.1, SMCCC 1.4
+efi0 at mainbus0: UEFI 2.7
+efi0: EFI Development Kit II / SbsaQemu rev 0x10000
+smbios0 at efi0: SMBIOS 3.4.0
+smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024
+smbios0: QEMU QEMU SBSA-REF Machine
+cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3
+cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache
+cpu0: 0KB 64b/line 8-way L2 cache
+cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR,MTE
+agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller"
+agintcmsi0 at agintc0
+agtimer0 at mainbus0: 62500 kHz
+acpi0 at mainbus0: ACPI 6.0
+acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+acpimcfg0 at acpi0
+acpimcfg0: addr 0xf0000000, bus 0-255
+acpiiort0 at acpi0
+pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33
+pluart0: console
+ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0
+ahci0: port 0: 1.5Gb/s
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_
+sd0: 43MB, 512 bytes/sector, 88064 sectors, thin
+xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0
+usb0 at xhci0: USB revision 3.0
+uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
+acpipci0 at acpi0 PCI0
+pci0 at acpipci0
+0:1:0: rom address conflict 0xfffc0000/0x40000
+0:2:0: rom address conflict 0xffff8000/0x8000
+"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
+em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56
+"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+```
diff --git a/results/classifier/108/other/2225 b/results/classifier/108/other/2225
new file mode 100644
index 000000000..72601b3d3
--- /dev/null
+++ b/results/classifier/108/other/2225
@@ -0,0 +1,26 @@
+graphic: 0.813
+device: 0.731
+performance: 0.720
+semantic: 0.612
+permissions: 0.394
+network: 0.304
+debug: 0.301
+boot: 0.260
+PID: 0.216
+vnc: 0.211
+socket: 0.152
+files: 0.152
+other: 0.131
+KVM: 0.107
+
+Mouse capture doesn't actually capture (GTK)
+Description of problem:
+The mouse is never actually captured by the window, you can always move it off screen, and because the guest OS has no awareness of the absolute mouse position there are many situations where you can't actually click something in the guest OS because the host mouse cursor is out of the window so clicking clicks on another program's window. It's unusable.
+
+It's clear that the problem is that the cursor isn't actually captured, if it ever was then the problem wouldn't occur. When the mouse is "uncaptured" we see the host cursor at all times and the guest cursor simply doesn't move, but when it's """captured""" the guest cursor still moves freely, it's just hidden while hovering the entire window (and not just the guest rectangle but really the whole thing) and the host cursor moves too at its own pace.
+
+It happens with `-display gtk` but not `-display sdl`.
+Steps to reproduce:
+1. Launch windowed guest
+2. Click on window
+3. Try to move mouse out of the window
diff --git a/results/classifier/108/other/2226 b/results/classifier/108/other/2226
new file mode 100644
index 000000000..eacf06bb2
--- /dev/null
+++ b/results/classifier/108/other/2226
@@ -0,0 +1,71 @@
+boot: 0.855
+socket: 0.855
+graphic: 0.852
+performance: 0.802
+vnc: 0.795
+permissions: 0.790
+device: 0.777
+debug: 0.738
+PID: 0.702
+network: 0.683
+files: 0.660
+semantic: 0.609
+KVM: 0.509
+other: 0.426
+
+arm HSTR trap settings routed to EL1 instead of EL2
+Description of problem:
+ARM's HSTR register is used to trap CP15 access from EL1/0. qemu's implementation seems to be inconsistent with ARM's documentation.
+
+Take the system register VBAR for example, the following pseudo code is grabbed from ARM DDI 0487J.a ID042523 G8-10651, which is the logics behind when reading VBAR.
+```
+if PSTATE.EL == EL0 then
+    UNDEFINED;
+elsif PSTATE.EL == EL1 then
+    if EL2Enabled() && !ELUsingAArch32(EL2) && HSTR_EL2.T12 == '1' then
+        AArch64.AArch32SystemAccessTrap(EL2, 0x03);
+    elsif EL2Enabled() && ELUsingAArch32(EL2) && HSTR.T12 == '1' then
+        AArch32.TakeHypTrapException(0x03);
+    elsif HaveEL(EL3) && ELUsingAArch32(EL3) then
+        R[t] = VBAR_NS;
+    else
+        R[t] = VBAR;
+elsif PSTATE.EL == EL2 then
+    if HaveEL(EL3) && ELUsingAArch32(EL3) then
+        R[t] = VBAR_NS;
+    else
+        R[t] = VBAR;
+elsif PSTATE.EL == EL3 then
+    if SCR.NS == '0' then
+        R[t] = VBAR_S;
+    else
+        R[t] = VBAR_NS;
+```
+
+The main logics in my attached test program are:
+1. Setting EL2 and EL1's exception table
+2. Set HSTR.T12
+3. ERET to EL1, and read VBAR from EL1
+
+As the document mentions, when CPU running on EL1 && HSTR.T12 is set, HypTrapException 0x3 should be taken, which is EL2. But the test program shows, on such circumstances, CPU is being routed to EL1's undefined exception.
+Steps to reproduce:
+1. Clone this repo https://github.com/roolrz/reproduce-qemu-arm-hstr-issue
+2. Use make to build the test program
+3. Use following command to launch it
+```
+qemu-system-arm \
+	-nographic \
+	-cpu cortex-a7 \
+	-M virt,virtualization=on \
+	-m 1G \
+	-kernel el2.elf
+```
+4. The following message is printed by the program, problem reproduced
+```
+EL2 Booted
+Jumping to el1
+el1 reached, triggering trap
+EL1 undefined sync triggered
+```
+Additional information:
+
diff --git a/results/classifier/108/other/2228 b/results/classifier/108/other/2228
new file mode 100644
index 000000000..9e7248add
--- /dev/null
+++ b/results/classifier/108/other/2228
@@ -0,0 +1,23 @@
+network: 0.838
+device: 0.829
+graphic: 0.827
+performance: 0.708
+socket: 0.706
+PID: 0.664
+debug: 0.516
+files: 0.514
+vnc: 0.496
+boot: 0.427
+semantic: 0.227
+permissions: 0.220
+KVM: 0.147
+other: 0.050
+
+hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed
+Description of problem:
+It's quite easy to trigger the assertion ``hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed``
+Steps to reproduce:
+Run one of the following command lines:
+1. ``./qemu-system-aarch64 -display none -machine qcom-dc-scm-v1-bmc -device max1111``
+2. ``./qemu-system-aarch64 -display none -machine fby35-bmc -device max1110``
+3. ``./qemu-system-aarch64 -display none -machine yosemitev2-bmc -device corgi-ssp``
diff --git a/results/classifier/108/other/2229 b/results/classifier/108/other/2229
new file mode 100644
index 000000000..384adb3f8
--- /dev/null
+++ b/results/classifier/108/other/2229
@@ -0,0 +1,20 @@
+device: 0.901
+network: 0.879
+PID: 0.777
+socket: 0.773
+performance: 0.745
+graphic: 0.745
+vnc: 0.668
+files: 0.667
+boot: 0.526
+debug: 0.444
+other: 0.442
+permissions: 0.279
+semantic: 0.256
+KVM: 0.086
+
+tcg/tcg.c:813:tcg_register_thread: assertion failed: (n < tcg_max_ctxs)
+Description of problem:
+When running qemu-system-microblazeel with the xlnx-zynqmp-pmu machine and an additional xlnx-zynqmp-pmu-soc device, TCG crashes via an assertion.
+Steps to reproduce:
+Run: `` ./qemu-system-microblazeel -machine xlnx-zynqmp-pmu -device xlnx-zynqmp-pmu-soc ``