1 files changed, 101 insertions, 0 deletions
diff --git a/results/classifier/118/architecture-i386/1823831 b/results/classifier/118/architecture-i386/1823831
new file mode 100644
index 000000000..04cf0175f
--- /dev/null
+++ b/results/classifier/118/architecture-i386/1823831
@@ -0,0 +1,101 @@
+i386: 0.834
+hypervisor: 0.819
+architecture: 0.808
+device: 0.712
+x86: 0.705
+performance: 0.687
+boot: 0.645
+ppc: 0.586
+semantic: 0.572
+kernel: 0.561
+socket: 0.553
+network: 0.522
+PID: 0.496
+VMM: 0.493
+permissions: 0.485
+user-level: 0.464
+risc-v: 0.454
+register: 0.453
+peripherals: 0.429
+TCG: 0.407
+graphic: 0.400
+debug: 0.400
+vnc: 0.390
+files: 0.385
+mistranslation: 0.376
+virtual: 0.348
+arm: 0.326
+assembly: 0.314
+KVM: 0.239
+--------------------
+i386: 0.984
+x86: 0.964
+debug: 0.834
+boot: 0.708
+hypervisor: 0.671
+kernel: 0.182
+virtual: 0.105
+files: 0.021
+network: 0.012
+TCG: 0.009
+PID: 0.008
+register: 0.007
+device: 0.005
+user-level: 0.004
+architecture: 0.004
+semantic: 0.004
+socket: 0.003
+performance: 0.002
+assembly: 0.002
+vnc: 0.001
+risc-v: 0.001
+graphic: 0.001
+VMM: 0.001
+permissions: 0.001
+peripherals: 0.001
+mistranslation: 0.001
+ppc: 0.001
+KVM: 0.000
+arm: 0.000
+
+BSD bootloader halts with hypervisor.framework
+
+Guest: FreeBSD 12.0 Install CD
+Host: MacOS 11.14.3 qemu master at 90fb864a7df0a9af677352e94f8225f7b03de922
+
+Command arguments:
+
+qemu-system-x86_64 -m 4000m -cdrom Downloads/FreeBSD-12.0-RELEASE-amd64-bootonly.iso
+
+When qemu was run with -accel hvf, the bootloader would halt after showing the menu. The bootloader would not respond to any keyboard events.
+
+Without acceleration option, the bootloader would count down to zero and proceed.
+
+Git bisect shows that 92d5f1a4147c3722b5e9a8bcfb7dc261b7a8b855 is the first bad commit.
+
+Author: Paolo Bonzini <email address hidden>
+Date:   Tue Aug 21 15:31:24 2018 +0200
+
+    target/i386: unify masking of interrupts
+    
+    Interrupt handling depends on various flags in env->hflags or env->hflags2,
+    and the exact detail were not exactly replicated between x86_cpu_has_work
+    and x86_cpu_exec_interrupt.  Create a new function that extracts the
+    highest-priority non-masked interrupt, and use it in both functions.
+
+In good versions (27e18b8952f8b7a1e26350846f8a0d5a9b33bfb8), calls to x86_cpu_has_work(), likely due to IRQ 0, returned interchanging true or false.
+
+In bad versions (92d5f1a4147c3722b5e9a8bcfb7dc261b7a8b855), all calls returned false.
+
+Hi Chen,
+
+Do you see the issue on the latest version of QEMU (v5.0 or master)?
+
+The fix addressed incorrect IRQ inhibition:
+https://git.qemu.org/?p=qemu.git;a=commit;h=ddd31732a7379e056749836ff37ff57718083ddb
+
+Thanks,
+Roman
+
+Yes, I've verified. It boots after countdown and responds to keyboard events.
+