Gregory Haskins wrote: > On Tue, 2007-07-17 at 23:16 +1000, Rusty Russell wrote: > >> I have shied away from touching x86_emulate.c (it could definitely use >> some love, but it is forked from the Xen code, and it would be more >> productive to cross-merge fixes). >> > > On this topic, here's an idea I have been kicking around for a while: > > If the x86_emulate code is so buggy/incomplete, and the QEMU one seems > to be able to generally handle most situations...could we simply exit to > userspace and use the qemu emulator somehow? I realize the overhead is > greater, but slow+working is > fast+broken in my book ;) > > Perhaps a hybrid solution would work? E.g. exit to qemu emulator when > the in-kernel stuff hits a mis-emulation point (do we realize this > consciously in the code, or only after the guest crashes?) > > I'm not really sure if this is plausible. Its just something I was > thinking about. > > It was once done that way (we started by having qemu emulate 32- and 16- bit code, then just 16-, then nothing). However, I'd like kvm to be independent of an external emulator, so that all cpu emulation is done in kernel.
Of course we have to have an in-kernel emulator, for page tables and for in-kernel mmio, so having a partial emulator in kernel and a full emulator in userspace seems messy. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
