add 18th iteration of classifier

1 files changed, 51 insertions, 0 deletions

diff --git a/results/classifier/118/performance/1589257 b/results/classifier/118/performance/1589257
new file mode 100644
index 000000000..09a381ebc
--- /dev/null
+++ b/results/classifier/118/performance/1589257
@@ -0,0 +1,51 @@
+performance: 0.963
+boot: 0.913
+network: 0.876
+peripherals: 0.839
+device: 0.826
+architecture: 0.776
+virtual: 0.680
+graphic: 0.652
+kernel: 0.586
+mistranslation: 0.585
+vnc: 0.546
+arm: 0.474
+semantic: 0.473
+user-level: 0.449
+debug: 0.417
+socket: 0.411
+permissions: 0.390
+register: 0.359
+risc-v: 0.351
+hypervisor: 0.329
+VMM: 0.316
+PID: 0.301
+i386: 0.297
+ppc: 0.283
+x86: 0.277
+assembly: 0.221
+files: 0.208
+TCG: 0.156
+KVM: 0.127
+
+Boot with OVMF extremely slow to bootloader
+
+I have used Arch Linux in the past with the same version (2.5.0), the exact same OVMF code and vars, and the exact same VM settings with no issues. Now with Ubuntu, I am having the issue where boot up until Windows takes about 10x longer. Every CPU thread/core allocated gets used 100% while this is happening. After that, everything operates as normal. There is no abnormal logs produced by qemu, or I don't know how to debug.
+
+Here are my settings:
+
+Host:
+Ubuntu 16.04
+Qemu 2.5.0
+Relevant configs attached
+
+Guest:
+Windows 10
+VirtIO raw disk image
+VirtIO network
+Typical VGA passthrough setup, everything operating normally
+
+
+
+I've solved the problem by using the ovmf package in apt instead of the firmware I've had before. Apparently, the older firmware was only compatible with an older kernel, and a newer kernel with the older firmware would cause the issue.
+