add 18th iteration of classifier

1 files changed, 90 insertions, 0 deletions

diff --git a/results/classifier/118/architecture-x86/1785308 b/results/classifier/118/architecture-x86/1785308
new file mode 100644
index 00000000..6448b05e
--- /dev/null
+++ b/results/classifier/118/architecture-x86/1785308
@@ -0,0 +1,90 @@
+x86: 0.918
+architecture: 0.914
+graphic: 0.874
+KVM: 0.829
+user-level: 0.809
+performance: 0.803
+virtual: 0.774
+hypervisor: 0.739
+semantic: 0.723
+device: 0.719
+register: 0.704
+socket: 0.676
+debug: 0.672
+ppc: 0.624
+kernel: 0.603
+files: 0.580
+PID: 0.579
+TCG: 0.560
+permissions: 0.560
+network: 0.548
+vnc: 0.527
+risc-v: 0.518
+boot: 0.508
+mistranslation: 0.482
+peripherals: 0.436
+assembly: 0.418
+VMM: 0.414
+i386: 0.378
+arm: 0.252
+--------------------
+x86: 0.999
+debug: 0.968
+virtual: 0.815
+i386: 0.540
+TCG: 0.052
+register: 0.037
+PID: 0.031
+performance: 0.022
+socket: 0.022
+files: 0.020
+architecture: 0.018
+user-level: 0.015
+KVM: 0.014
+kernel: 0.014
+boot: 0.013
+device: 0.012
+risc-v: 0.010
+vnc: 0.010
+hypervisor: 0.009
+semantic: 0.008
+network: 0.007
+assembly: 0.005
+VMM: 0.004
+graphic: 0.002
+peripherals: 0.002
+permissions: 0.002
+ppc: 0.002
+mistranslation: 0.001
+arm: 0.000
+
+0x8 exception encountered but not handled
+
+Present in all QEMU versions.
+
+OS is triple page faulting and crashing rather than handling the expected double page fault properly. The same OS works in Bochs so I know its not the problem.
+
+Hi Ra,
+  We'll need a bit more detail to be able to help here.
+The fact something works in Bochs but doesn't work in qemu doesn't necessarily mean it's a qemu bug - for example the OS might be hitting something undefined or a timing issue; so we'd need some information on how the double page fault happened.
+Does it work with KVM enabled? With tcg? What version of qemu are you using?
+
+Hi David,
+    The OS is hitting something undefined. It's built on exploiting the x86 architecture to run computations of the MMU rather than the CPU: https://github.com/jbangert/trapcc
+I've tried it on the 3 most recent versions of QEMU for Windows. I'll give it a go with KVM and tcg and get back to you although I'm not hopeful.  
+
+OK, that's just a cruel test :-)
+It'll be interesting to see the difference between TCG and KVM, but with such a weird test case as that you'll probably need to narrow the problem down more.
+
+
+What would be useful information to narrow down the problem? Any specific kind of logs from running it in TCG and KVM?
+
+I think I'd start by seeing if it fails in both or if they're different.
+If they're different then you'd follow the series of exceptions that they each get
+and see where they diverge.
+
+More generally, I think that if you care about getting this test case to work under QEMU emulation you're going to have to be prepared to dig into QEMU's internals to debug where we diverge from what the real CPU does. Our x86 emulation is not very actively maintained and this isn't a "real world" use case that many users are going to have problems with, so my guess is it is unlikely to be fixed unless somebody with enough interest in it to take a day or a week to debug what's going on does that work.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+