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.]