Glauber Costa writes ("[PATCH] hook cpu running at a higher level."):
> This patch removes the kvm_enabled() check from cpu-exec.c.
> This file is highly tcg-specific, and we'll probably want it
> out when tcg is not compiled in (coming soon, in a theathe near you)That would be interesting, certainly. We don't compile that file anyway right now, and have our own version of exec.c too (sadly it's somewhat clone-and-hack and it would be nice to make that neater in due course). > Instead, we hook at the main loop level. The amount of code > duplication introduced is at worst, acceptable, and I believe > it pays. The tcg mainloop is likely to be different from the > hypervisors ones, since tcg runs all cpus in lockstep. KVM > (and probably xen), will be able to span threads out for its > vcpus. I don't have an opinion about this patch really, but I did want to comment slightly on the way Xen does things just for future reference. The Xen qemu process runs only in one thread which is fine because it doesn't need to be involved with actual processor execution. In theory parallel execution (in different threads and thus on different physical cpus) of IO emulations requested by different guest vcpus might make some small performance difference but I doubt it would be worth our while. So I think the Xen setup will still from qemu's point of view look like a single vcpu no matter how many vcpus the guest aactually has. > - main_loop(); > + if (kvm_enabled()) > + kvm_main_loop(); > + else > + main_loop(); > + The way we have approached these problems in the Xen tree is to supply an alternative implementation of (say) main_loop and arrange for the standard one not to be compiled. Is it the intent to make kvm a run-time selectable option ? It seems to me that that given that we already have different qemu builds for all of the various target (guest) cpu architectures, it might be simpler to continue that approach. With a bit of judicious movement of code into appropriate files, this will avoid the need for ifs and ifdefs. Regards, Ian. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
