summary refs log tree commit diff stats
path: root/results/classifier/108/other/1836
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/183616
-rw-r--r--results/classifier/108/other/1836078252
-rw-r--r--results/classifier/108/other/183613627
-rw-r--r--results/classifier/108/other/183619250
-rw-r--r--results/classifier/108/other/183643032
-rw-r--r--results/classifier/108/other/183645138
-rw-r--r--results/classifier/108/other/1836501141
-rw-r--r--results/classifier/108/other/183653729
-rw-r--r--results/classifier/108/other/1836762166
9 files changed, 751 insertions, 0 deletions
diff --git a/results/classifier/108/other/1836 b/results/classifier/108/other/1836
new file mode 100644
index 00000000..3c0aa5b2
--- /dev/null
+++ b/results/classifier/108/other/1836
@@ -0,0 +1,16 @@
+other: 0.914
+device: 0.646
+performance: 0.554
+graphic: 0.447
+boot: 0.441
+semantic: 0.398
+network: 0.226
+permissions: 0.218
+debug: 0.145
+vnc: 0.132
+socket: 0.089
+files: 0.054
+PID: 0.011
+KVM: 0.005
+
+AIX no longer boots
diff --git a/results/classifier/108/other/1836078 b/results/classifier/108/other/1836078
new file mode 100644
index 00000000..a5ec2ed4
--- /dev/null
+++ b/results/classifier/108/other/1836078
@@ -0,0 +1,252 @@
+permissions: 0.900
+other: 0.860
+semantic: 0.835
+graphic: 0.815
+debug: 0.787
+device: 0.784
+performance: 0.783
+PID: 0.757
+socket: 0.712
+network: 0.678
+vnc: 0.672
+boot: 0.663
+files: 0.645
+KVM: 0.626
+
+Regressions on arm-linux-gnueabihf target with some GCC tests
+
+Hi,
+
+After trying qemu master:
+commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
+Merge: 68d7ff0 14f5d87
+Author: Peter Maydell <email address hidden>
+Date: Fri Jun 21 15:40:50 2019 +0100
+
+even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
+I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
+I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.
+
+All tests used to pass w/o error, but with a recent qemu, all of them make qemu crash.
+
+This was noticed with GCC master configured with
+--target arm-none-linux-gnueabihf
+--with-cpu cortex-a57
+--with-fpu crypto-neon-fp-armv8
+
+Thanks
+
+
+
+I bisected the failure for all but the IEEE6 test to:
+
+commit 602f6e42cfbfe9278be34e9b91d2ceb695837e02
+Author: Peter Maydell <email address hidden>
+Date:   Thu Feb 28 10:55:16 2019 +0000
+
+    target/arm: Use MVFR1 feature bits to gate A32/T32 FP16 instructions
+
+    Instead of gating the A32/T32 FP16 conversion instructions on
+    the ARM_FEATURE_VFP_FP16 flag, switch to our new approach of
+    looking at ID register bits. In this case MVFR1 fields FPHP
+    and SIMDHP indicate the presence of these insns.
+
+    This change doesn't alter behaviour for any of our CPUs.
+
+    Signed-off-by: Peter Maydell <email address hidden>
+    Reviewed-by: Richard Henderson <email address hidden>
+    Message-id: <email address hidden>
+
+
+The IEEE6 test comes down to:
+
+commit a15945d98d3a3390c3da344d1b47218e91e49d8b
+Author: Peter Maydell <email address hidden>
+Date:   Tue Feb 5 16:52:42 2019 +0000
+
+    target/arm: Make FPSCR/FPCR trapped-exception bits RAZ/WI
+
+    The {IOE, DZE, OFE, UFE, IXE, IDE} bits in the FPSCR/FPCR are for
+    enabling trapped IEEE floating point exceptions (where IEEE exception
+    conditions cause a CPU exception rather than updating the FPSR status
+    bits). QEMU doesn't implement this (and nor does the hardware we're
+    modelling), but for implementations which don't implement trapped
+    exception handling these control bits are supposed to be RAZ/WI.
+    This allows guest code to test for whether the feature is present
+    by trying to write to the bit and checking whether it sticks.
+
+    QEMU is incorrectly making these bits read as written. Make them
+    RAZ/WI as the architecture requires.
+
+    In particular this was causing problems for the NetBSD automatic
+    test suite.
+
+    Reported-by: Martin Husemann <email address hidden>
+    Signed-off-by: Peter Maydell <email address hidden>
+    Reviewed-by: Richard Henderson <email address hidden>
+    Message-id: <email address hidden>
+
+
+
+In the ieee6 test case it is attempting to write OFE, bit [10] which:
+
+    This bit is RW only if the implementation supports the trapping of floating-point exceptions. In an implementation that does not support floating-point exception trapping, this bit is RAZ/WI.
+
+    When this bit is RW, it applies only to floating-point operations. Advanced SIMD operations always use untrapped floating-point exception handling in AArch32 state
+
+This might be a broken test.
+
+When we converted to using feature bits in 602f6e42cfbf we missed out
+the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
+-cpu max configurations. This caused a regression in the GCC test
+suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP.
+
+Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
+Signed-off-by: Alex Bennée <email address hidden>
+---
+ target/arm/cpu.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/target/arm/cpu.c b/target/arm/cpu.c
+index e75a64a25a..0a0a202fe3 100644
+--- a/target/arm/cpu.c
++++ b/target/arm/cpu.c
+@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
+             t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
+             cpu->isar.id_isar6 = t;
+ 
++            t = cpu->isar.mvfr1;
++            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.2 FP16 */
++            cpu->isar.mvfr1 = t;
++
+             t = cpu->isar.mvfr2;
+             t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
+             t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
+-- 
+2.20.1
+
+
+
+
+Richard Henderson <email address hidden> writes:
+
+> On 7/10/19 7:24 PM, Alex Bennée wrote:
+>> When we converted to using feature bits in 602f6e42cfbf we missed out
+>> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
+>> -cpu max configurations. This caused a regression in the GCC test
+>> suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP.
+>>
+>> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
+>> Signed-off-by: Alex Bennée <email address hidden>
+>> ---
+>>  target/arm/cpu.c | 4 ++++
+>>  1 file changed, 4 insertions(+)
+>>
+>> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
+>> index e75a64a25a..0a0a202fe3 100644
+>> --- a/target/arm/cpu.c
+>> +++ b/target/arm/cpu.c
+>> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
+>>              t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
+>>              cpu->isar.id_isar6 = t;
+>>
+>> +            t = cpu->isar.mvfr1;
+>> +            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.2 FP16 */
+>
+> The comment is wrong.  This is not full v8.2 FP16 support (which would be value
+> 3, plus a change to SIMDHP), but v8.0 support for double<->half
+> conversions.
+
+Good catch - will fix in v2.
+>
+> Otherwise,
+> Reviewed-by: Richard Henderson <email address hidden>
+>
+>
+> r~
+
+
+--
+Alex Bennée
+
+
+When we converted to using feature bits in 602f6e42cfbf we missed out
+the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
+-cpu max configurations. This caused a regression in the GCC test
+suite. Fix this by setting the appropriate bits in mvfr1.FPHP to
+report ARMv8-A with FP support (but not ARMv8.2-FP16).
+
+Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
+Signed-off-by: Alex Bennée <email address hidden>
+Reviewed-by: Richard Henderson <email address hidden>
+---
+ target/arm/cpu.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/target/arm/cpu.c b/target/arm/cpu.c
+index e75a64a25a..ad164a773b 100644
+--- a/target/arm/cpu.c
++++ b/target/arm/cpu.c
+@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
+             t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
+             cpu->isar.id_isar6 = t;
+ 
++            t = cpu->isar.mvfr1;
++            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.0 FP support */
++            cpu->isar.mvfr1 = t;
++
+             t = cpu->isar.mvfr2;
+             t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
+             t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
+-- 
+2.20.1
+
+
+
+On Thu, 11 Jul 2019 at 11:37, Alex Bennée <email address hidden> wrote:
+>
+> When we converted to using feature bits in 602f6e42cfbf we missed out
+> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
+> -cpu max configurations. This caused a regression in the GCC test
+> suite. Fix this by setting the appropriate bits in mvfr1.FPHP to
+> report ARMv8-A with FP support (but not ARMv8.2-FP16).
+>
+> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
+> Signed-off-by: Alex Bennée <email address hidden>
+> Reviewed-by: Richard Henderson <email address hidden>
+> ---
+>  target/arm/cpu.c | 4 ++++
+>  1 file changed, 4 insertions(+)
+>
+> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
+> index e75a64a25a..ad164a773b 100644
+> --- a/target/arm/cpu.c
+> +++ b/target/arm/cpu.c
+> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
+>              t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
+>              cpu->isar.id_isar6 = t;
+>
+> +            t = cpu->isar.mvfr1;
+> +            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.0 FP support */
+> +            cpu->isar.mvfr1 = t;
+> +
+>              t = cpu->isar.mvfr2;
+>              t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
+>              t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
+> --
+> 2.20.1
+
+
+
+Applied to target-arm.next, thanks.
+
+-- PMM
+
+
+I confirm this patch fixes the problem I reported.
+Thanks!
+
+I think the ieee6 test is due to a broken runtime: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=45b1a243b81a7c9ae562
+
diff --git a/results/classifier/108/other/1836136 b/results/classifier/108/other/1836136
new file mode 100644
index 00000000..5e92608c
--- /dev/null
+++ b/results/classifier/108/other/1836136
@@ -0,0 +1,27 @@
+boot: 0.751
+device: 0.646
+graphic: 0.590
+semantic: 0.424
+other: 0.345
+socket: 0.293
+files: 0.201
+PID: 0.153
+permissions: 0.112
+network: 0.099
+debug: 0.091
+vnc: 0.082
+performance: 0.055
+KVM: 0.010
+
+u-boot: any plans to update u-boot to v2019.07
+
+Just want to pulse about the plan to update u-boot binary to latest v2019.07.
+
+Are there any notable bugfixes or new features that this would get us for the two platforms where we ship a u-boot binary ?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+As it happens, in April 2021 commit 335b6389374a53e0 bumped our u-boot rom to v2021.04 to fix a PCI issue.
+
+
diff --git a/results/classifier/108/other/1836192 b/results/classifier/108/other/1836192
new file mode 100644
index 00000000..fd92f9f4
--- /dev/null
+++ b/results/classifier/108/other/1836192
@@ -0,0 +1,50 @@
+other: 0.793
+device: 0.784
+debug: 0.773
+performance: 0.771
+files: 0.763
+PID: 0.734
+boot: 0.695
+semantic: 0.685
+network: 0.682
+permissions: 0.651
+vnc: 0.638
+graphic: 0.634
+socket: 0.593
+KVM: 0.524
+
+Regressions on arm926 target with some GCC tests
+
+Hi,
+
+After trying qemu master:
+commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
+Merge: 68d7ff0 14f5d87
+Author: Peter Maydell <email address hidden>
+Date: Fri Jun 21 15:40:50 2019 +0100
+
+even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
+I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite, with GCC configured to generate arm10tdmi code by default, and using qemu's --cpu arm926.
+
+I'm attaching a tarball containing one of the GCC tests (binaries), needed shared libs, and a short script to run the test.
+
+This was noticed with GCC master configured with
+--target arm-none-linux-gnueabi
+--with-cpu arm10tdmi
+--with-fpu vfp
+
+Thanks
+
+
+
+We didn't spot that armv5 CPUs don't have mvfr0, so now the vfp refactor is looking at mvfr0 fields to gate feature presence we need to initialize cpu->isar.mvfr0 specifically to a value that indicates the right thing even on the armv5 CPUs which don't have a guest-visible mvfr0. This specifically affects just arm926 and arm1026, which have accidentally lost short-vector support and double-precision support.
+
+
+We didn't spot that armv5 CPUs don't have mvfr0, so now the vfp refactor is looking at mvfr0 fields to gate feature presence we need to initialize cpu->isar.mvfr0 specifically to a value that indicates the right thing even on the armv5 CPUs which don't have a guest-visible mvfr0. This specifically affects just arm926 and arm1026, which have accidentally lost short-vector support and double-precision support.
+
+
+I confirm this patch fixes the problem I reported. Thanks!
+
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cb7cef8b32033f6284a47d797
+
diff --git a/results/classifier/108/other/1836430 b/results/classifier/108/other/1836430
new file mode 100644
index 00000000..2f7879cb
--- /dev/null
+++ b/results/classifier/108/other/1836430
@@ -0,0 +1,32 @@
+graphic: 0.770
+device: 0.520
+performance: 0.508
+semantic: 0.475
+socket: 0.321
+vnc: 0.313
+network: 0.286
+files: 0.284
+other: 0.281
+permissions: 0.224
+PID: 0.216
+KVM: 0.191
+boot: 0.189
+debug: 0.161
+
+Can't install on Windows 10
+
+Latest release (20190712) 64-bit doesn't install:
+
+The setup seems to work fine at first and actually extract all the files needed for qemu in the correct location, but after it has done that, it proceeds to delete every file and leaves no trace of qemu except the installation folder.
+The setup then finishes and notifies the user that it has been installed succesfully.
+
+I downloaded the previous release and it installs correctly.
+
+I just ran the installer from: 
+ 
+  https://qemu.weilnetz.de/w64/qemu-w64-setup-20190713.exe
+  
+on a Win10 VM and it successfully installed and I checked for the files in Program Files and they were all there. Can you re-test with the latest installer please?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1836451 b/results/classifier/108/other/1836451
new file mode 100644
index 00000000..b87d833b
--- /dev/null
+++ b/results/classifier/108/other/1836451
@@ -0,0 +1,38 @@
+device: 0.891
+graphic: 0.700
+PID: 0.665
+network: 0.600
+socket: 0.581
+other: 0.539
+semantic: 0.498
+files: 0.479
+vnc: 0.462
+boot: 0.419
+performance: 0.388
+debug: 0.362
+permissions: 0.306
+KVM: 0.260
+
+'make info' fails due to errors in qemu-tech.texi
+
+git tag: v4.1.0-rc0
+host: Fedora 29, x86_64
+
+$ make info
+make[1]: Entering directory 'qemu/slirp'
+make[1]: Nothing to be done for 'all'.
+make[1]: Leaving directory 'qemu/slirp'
+  GEN     docs/version.texi
+  GEN     qemu-options.texi
+  GEN     qemu-monitor.texi
+  GEN     qemu-img-cmds.texi
+  GEN     qemu-monitor-info.texi
+  GEN     qemu-doc.info
+qemu/qemu-tech.texi:6: @menu reference to nonexistent node `Translator Internals'
+qemu/qemu-tech.texi:7: @menu reference to nonexistent node `QEMU compared to other emulators'
+qemu/qemu-tech.texi:9: @menu reference to nonexistent node `Bibliography'
+Makefile:960: recipe for target 'qemu-doc.info' failed
+make: *** [qemu-doc.info] Error 1
+
+Fixed by commit 32481687e1a262.
+
diff --git a/results/classifier/108/other/1836501 b/results/classifier/108/other/1836501
new file mode 100644
index 00000000..04eba70e
--- /dev/null
+++ b/results/classifier/108/other/1836501
@@ -0,0 +1,141 @@
+semantic: 0.949
+other: 0.945
+graphic: 0.923
+permissions: 0.912
+debug: 0.891
+performance: 0.890
+device: 0.888
+PID: 0.826
+boot: 0.819
+files: 0.769
+socket: 0.717
+KVM: 0.695
+network: 0.631
+vnc: 0.619
+
+cpu_address_space_init fails with assertion
+
+qemu-system-arm does not start with version >= 2.6 and KVM enabled.
+
+  cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()' failed.
+
+Hardware is Odroid XU4 with Exynos with 4.9.61+ Tested with Debian Stretch (9) or Buster (10).
+
+Without KVM it is running fine but slow. I'm operating Debian Jessie with qemu 2.1 for a long time with KVM virtualization working flawlessly. When I upgraded to Stretch I ran into the trouble described before. I tried Debian Stretch and Buster with all Kernels provided by the Board manufacturer (Hardkernel).
+
+It seems to be related to the feature introduced in Version 2.6:
+https://wiki.qemu.org/ChangeLog/2.6
+- Support for a separate EL3 address space
+
+KVM is enabled, so I assume the adress space index asidx to be causing the assert to fail.
+
+dmesg | grep -i KVM
+[    0.741714] kvm [1]: 8-bit VMID
+[    0.741721] kvm [1]: IDMAP page: 40201000
+[    0.741729] kvm [1]: HYP VA range: c0000000:ffffffff
+[    0.742543] kvm [1]: Hyp mode initialized successfully
+[    0.742600] kvm [1]: vgic-v2@10484000
+[    0.742924] kvm [1]: vgic interrupt IRQ16
+[    0.742943] kvm [1]: virtual timer IRQ60
+
+Full command line is:
+qemu-system-arm -M vexpress-a15 -smp 2 -m 512 -cpu host -enable-kvm -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device virtio-blk-device,drive=inst-blk -drive file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw console=ttyAMA0" -nographic
+
+Is there anything to do to understand, if this is a hardware related failure or probably just a missing parameter?
+
+Regards
+
+Lutz
+
+2.6 is now very old -- can you check whether this is still a problem with a more recent QEMU version, please?
+
+The command line you're using should in theory work, but vexpress-a15 + KVM is a bit of an obscure combination -- most people who want to use virtualization use the 'virt' machine, which supports more RAM and has PCI, unlike the vexpress-a15 board. So it's possible we broke it by accident and didn't notice.
+
+
+Oh, I've just noticed -- we default to enabling EL3 on this board (like the hardware), which won't work with KVM, so if you want KVM you need to disable EL3 with the command line option -machine secure=off
+
+
+We do check for the incompatible option combination in hw/arm/virt.c:
+    if (vms->secure) {
+        if (kvm_enabled()) {
+            error_report("mach-virt: KVM does not support Security extensions");
+            exit(1);
+        }
+
+we just don't have anything equivalent in vexpress.c. We should probably put something in target/arm/cpu.c so we don't have to modify every board.
+
+
+Thank you for the quick and complete investigation. I'll follow your suggestions and will reply any succecss in the next days. I checked the source of the vexpress and found the assert, but wasn't clever enough to compare it to another board.
+
+I would support the idea of checking the incompatible parameter pairing in common code.
+
+I've now tested this with both current head-of-git and with the Debian stretch 2.8.1 qemu-system-arm and I can't reproduce this. We automatically don't enable the EL3 feature if we're using KVM, so a guest runs and sees a non-secure only CPU, without needing to manually add -machine secure=off to the command line. Perhaps we fixed it between 2.6 and 2.8 ?
+
+
+My test setup is now Debian Buster with qemu-system-arm 3.1 and a host with KVM-enabled Kernel 4.9.61 on Odroid XU4.
+
+Following results:
+--------
+qemu-system-arm -M vexpress-a15 -smp 2 -m 512 -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device virtio-blk-device,drive=inst-blk -drive file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw console=ttyAMA0" -nographic -enable-kvm
+
+Still not working as above, so it doesn't seem to be fixed for 3.1.
+--------
+qemu-system-arm -M vexpress-a15,secure=off -smp 2 -m 512 -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device virtio-blk-device,drive=inst-blk -drive file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw console=ttyAMA0" -nographic -enable-kvm
+
+No errors but no output at all, can switch to qemu monitor, but don't know if system is running
+--------
+Option 1 and Option 2 both start the Debian installer as expected WITHOUT the parameter -enable-kvm
+
+
+I did also tests with the virt board as recommended. With the parameter -enable-kvm none of the different virt-* boards did output anything to the console, without KVM the virt-boards did start. 
+
+virt-2.6 and virt-2.7 did boot into the installer without KVM.
+
+Any more recent version (2.8, 2.9, 2.10, 3.0 and 3.1) returned
+
+"Unable to handle kernel paging request at virtual address 0109ed30" (address is changing)
+
+during the init process. With different guest memory sizes the paging error occurred at a different init step.
+
+Conclusion:
+1) EL3 feature does still seem to be enabled in qemu 3.1 (Debian) even for KVM-enabled guests.
+2) Any recommendation for a support forum to discuss my trouble with the missing console output when enabling KVM and the paging problems with the recent virt boards outside this bug report?
+
+UPDATE: Kernel page handling seems to be related to the -smp 2 parameter. Any number > 1 leads to the paging error while omitting the parameter lead to a running system (without KVM).
+
+I can boot a KVM guest (either with the debian stretch qemu-system-arm 2.8.1, or with a head-of-upstream-git QEMU), which wouldn't work with EL3 enabled, so I'm not sure what is going wrong for you. To try to debug this further you'd need to build QEMU from source and start running it under the debugger to see what exactly is going on and why it's hitting that assertion.
+
+I would be tempted to try a newer kernel to see if that helped. (My working setup is using the debian stretch stock "4.9.0-0.bpo.9-armmp-lpae #1 SMP Debian 4.9.168-1+deb9u3~deb8u1 (2019-06-17)", but in general 4.9 is fairly elderly now.)
+
+For forums to talk about this kind of thing you might also try the qemu-arm mailing list (https://lists.nongnu.org/mailman/listinfo/qemu-arm) or qemu-devel itself (generally best to cc qemu-devel on qemu-arm emails anyway, lots of people don't subscribe to the per-architecture lists).
+
+
+I'm marking this bug 'incomplete' since as in comment #8 I was unable to reproduce, and I'm no longer sure how the assert could be being hit. If you can provide repro instructions and images that work on current head-of-git I can investigate.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+I am having a similar problem. I want to use KVM on jetson nano and boot Raspbian Buster 32bit OS with native machine emulation.
+
+Run into a similar problem. I used latest QEMU. 
+
+
+When I use gdb i see that the assert line uses:
+
+   /* KVM cannot currently support multiple address spaces. */
+    assert(asidx == 0 || !kvm_enabled());
+
+the asidx is 1. So since KVM is not supporting multiple addresses spaces that the Raspi3 requires the assertion occurs.
+
+I wonder what the workaround could be for this 
+
+
+
+
+> I want to use KVM on jetson nano and boot Raspbian Buster 32bit OS with native machine emulation.
+
+The raspi machine doesn't support KVM. You can choose either (1) boot on a board model which does support KVM, which basically means "virt", or (2) use emulation, not KVM.
+
+If all you care about is running a fairly generic Linux userspace then option 1 will probably be good enough.
+
+
diff --git a/results/classifier/108/other/1836537 b/results/classifier/108/other/1836537
new file mode 100644
index 00000000..f6ec1c00
--- /dev/null
+++ b/results/classifier/108/other/1836537
@@ -0,0 +1,29 @@
+other: 0.917
+device: 0.874
+network: 0.776
+graphic: 0.708
+socket: 0.650
+semantic: 0.622
+boot: 0.614
+vnc: 0.608
+performance: 0.552
+permissions: 0.517
+KVM: 0.475
+PID: 0.472
+files: 0.369
+debug: 0.361
+
+Kconfig-related options not shown in ./configure --help
+
+tag: v4.1.0-rc0
+
+I notice these options not documented by '--help':
+
+  --with-default-devices) default_devices="yes"
+  --without-default-devices) default_devices="no"
+
+We might have other options not documented too.
+
+Fixed here:
+https://gitlab.com/qemu-project/qemu/-/commit/c035c8d6f54
+
diff --git a/results/classifier/108/other/1836762 b/results/classifier/108/other/1836762
new file mode 100644
index 00000000..66567d3b
--- /dev/null
+++ b/results/classifier/108/other/1836762
@@ -0,0 +1,166 @@
+graphic: 0.808
+KVM: 0.753
+other: 0.744
+permissions: 0.693
+vnc: 0.693
+device: 0.679
+debug: 0.606
+PID: 0.600
+performance: 0.577
+files: 0.574
+socket: 0.571
+boot: 0.535
+semantic: 0.505
+network: 0.440
+
+Many leaks from qemu_spice_create_update
+
+tag: v4.1.0-rc0
+
+Compiled with --enable-sanitizers
+
+$ qemu-system-x86_64 -device qxl-vga ...
+[guest exits calling 'hlt']
+==20452==ERROR: LeakSanitizer: detected memory leaks
+
+Direct leak of 167616 byte(s) in 582 object(s) allocated from:
+    #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef)
+    #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d)
+    #2 0x561148c6d547 in qemu_spice_create_update qemu/ui/spice-display.c:222:21
+    #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9
+    #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
+    #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13
+    #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5
+    #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9
+    #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12
+    #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25
+    #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5
+    #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9
+    #12 0x561147c4976d in main qemu/vl.c:4473:5
+    #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412)
+
+Direct leak of 5184 byte(s) in 18 object(s) allocated from:
+    #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef)
+    #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d)
+    #2 0x561148c6e3e7 in qemu_spice_create_update qemu/ui/spice-display.c:243:13
+    #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9
+    #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
+    #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13
+    #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5
+    #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9
+    #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12
+    #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25
+    #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5
+    #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9
+    #12 0x561147c4976d in main qemu/vl.c:4473:5
+    #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412)
+
+Direct leak of 2560 byte(s) in 4 object(s) allocated from:
+    #0 0x561146f2cb46 in realloc (x86_64-softmmu/qemu-system-x86_64+0x1824b46)
+    #1 0x7f73ac04c420  (/lib64/libfontconfig.so.1+0x21420)
+
+Direct leak of 22 byte(s) in 1 object(s) allocated from:
+    #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af)
+    #1 0x7f73ae781953 in XGetAtomName (/lib64/libX11.so.6+0x2a953)
+
+Indirect leak of 54936 byte(s) in 510 object(s) allocated from:
+    #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af)
+    #1 0x7f73af3dddc5 in g_malloc (/lib64/libglib-2.0.so.0+0x54dc5)
+    #2 0x561148c6d547 in qemu_spice_create_update qemu/ui/spice-display.c:222:21
+    #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9
+    #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
+    #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13
+    #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5
+    #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9
+    #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12
+    #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25
+    #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5
+    #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9
+    #12 0x561147c4976d in main qemu/vl.c:4473:5
+    #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412)
+
+Indirect leak of 30720 byte(s) in 23 object(s) allocated from:
+    #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af)
+    #1 0x7f73af3dddc5 in g_malloc (/lib64/libglib-2.0.so.0+0x54dc5)
+    #2 0x561148c6e3e7 in qemu_spice_create_update qemu/ui/spice-display.c:243:13
+    #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9
+    #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
+    #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13
+    #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5
+    #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9
+    #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12
+    #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25
+    #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5
+    #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9
+    #12 0x561147c4976d in main qemu/vl.c:4473:5
+    #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412)
+
+Indirect leak of 8288 byte(s) in 259 object(s) allocated from:
+    #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af)
+    #1 0x7f73ac0385af  (/lib64/libfontconfig.so.1+0xd5af)
+
+Indirect leak of 4068 byte(s) in 303 object(s) allocated from:
+    #0 0x561146e78f40 in __interceptor_strdup (x86_64-softmmu/qemu-system-x86_64+0x1770f40)
+    #1 0x7f73ac04bc44 in FcValueSave (/lib64/libfontconfig.so.1+0x20c44)
+
+Indirect leak of 2336 byte(s) in 73 object(s) allocated from:
+    #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef)
+    #1 0x7f73ac04c9cc  (/lib64/libfontconfig.so.1+0x219cc)
+
+Indirect leak of 1536 byte(s) in 48 object(s) allocated from:
+    #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef)
+    #1 0x7f73ac04bf0c  (/lib64/libfontconfig.so.1+0x20f0c)
+
+Indirect leak of 1440 byte(s) in 5 object(s) allocated from:
+    #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef)
+    #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d)
+    #2 0x561148c6e3e7 in qemu_spice_create_update qemu/ui/spice-display.c:243:13
+    #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9
+    #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
+    #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13
+    #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5
+    #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9
+    #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12
+    #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25
+    #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5
+    #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9
+    #12 0x561147c4976d in main qemu/vl.c:4473:5
+    #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412)
+
+Indirect leak of 1440 byte(s) in 5 object(s) allocated from:
+    #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef)
+    #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d)
+    #2 0x561148c6d547 in qemu_spice_create_update qemu/ui/spice-display.c:222:21
+    #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9
+    #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9
+    #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13
+    #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5
+    #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9
+    #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12
+    #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25
+    #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5
+    #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9
+    #12 0x561147c4976d in main qemu/vl.c:4473:5
+    #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412)
+
+Indirect leak of 384 byte(s) in 12 object(s) allocated from:
+    #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef)
+    #1 0x7f73ac04bd9e  (/lib64/libfontconfig.so.1+0x20d9e)
+
+Indirect leak of 96 byte(s) in 2 object(s) allocated from:
+    #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af)
+    #1 0x7f73ac045e51 in FcLangSetCreate (/lib64/libfontconfig.so.1+0x1ae51)
+
+SUMMARY: AddressSanitizer: 280628 byte(s) leaked in 1847 allocation(s).
+
+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 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 'invalid' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/231
+
+