On 17/07/07 08:41 -0500, Anthony Liguori wrote: >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?) >> > >SMP is really tricky in this environment. The code that QEMU generates >doesn't guarantee atomicity of instructions so if you have one CPU >running in QEMU and another running on bare metal and they both were >attempting to access a spin lock things would break down pretty quickly.
Another possibility is pulling x86_emulate into its own library that is shared by xen, kvm, and available for use by any other project. making it into an emulation library. Mike -- Mike Day http://www.ncultra.org AIM: ncmikeday | Yahoo IM: ultra.runner PGP key: http://www.ncultra.org/ncmike/pubkey.asc ------------------------------------------------------------------------- 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
