>> 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.
Actually this is how the first generation of KVM worked. Since Avi & Yaniv had bad experience with serializing the cpu state with qemu they droped this direction. Basically it could have been nice, Xen though of doing V2E migrations (virtual to emulate). I don't know if they implemented that. Anyway Nitin A Kamble works for finishing the in-kernel emulator. ------------------------------------------------------------------------- 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
