add 18th iteration of classifier

1 files changed, 52 insertions, 0 deletions

diff --git a/results/classifier/118/debug/1823998 b/results/classifier/118/debug/1823998
new file mode 100644
index 00000000..268c3dc0
--- /dev/null
+++ b/results/classifier/118/debug/1823998
@@ -0,0 +1,52 @@
+debug: 0.959
+architecture: 0.942
+arm: 0.831
+kernel: 0.821
+performance: 0.803
+boot: 0.796
+device: 0.775
+files: 0.685
+network: 0.616
+ppc: 0.596
+socket: 0.582
+register: 0.560
+permissions: 0.546
+mistranslation: 0.530
+PID: 0.520
+peripherals: 0.510
+x86: 0.509
+semantic: 0.506
+user-level: 0.501
+graphic: 0.451
+i386: 0.435
+VMM: 0.430
+vnc: 0.429
+hypervisor: 0.418
+TCG: 0.409
+risc-v: 0.399
+virtual: 0.392
+KVM: 0.379
+assembly: 0.265
+
+qemu-system-aarch64: support kernels bigger than 128MiB
+
+Presently QEMU reserves up to 128MiB of space for an arm64 Linux kernel, placing the initrd following this, and the dtb following the initrd.
+
+This is not sufficient for some debug configurations of the kernel, which can be larger than 128MiB. Depending on the relative size of the kernel Image and unpopulated BSS, the dtb (or kernel) will be clobbered by the other, resulting in a silent boot failure.
+
+Since v3.17, the kernel Image header exposes a field called image_size, which describes the entire size of the kernel (including unpopulated sections such as the BSS) as a 64-bit little-endian value. For kernels prior to v3.17, this field is zero. This is documented at:
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt?h=v5.0#n68
+
+It would be great if QEMU could take the image_size field into account when placing the initrd and dtb to avoid overlap with the kernel.
+
+I've submitted a patchset which I think should fix this, but if you could test that it actually does handle large images correctly that would be great.
+
+https://<email address hidden>/
+
+
+Changes now in master, will be in 4.1.
+
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5e6dbe1e8cbbe4b6f74
+