On Tue, Dec 30, 2008 at 8:24 AM, Ian Jackson > 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.
Is it one vcpu or various in lockstep ? If you have only one vcpu, your main loop can be even simpler than qemu's, which holds them all in a for 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. > I believe the idea here is to bring up something close to the accel patches (this one, plus the ones for memory_rw and registered I already posted). So you would not see this, but simply "cpu_main_loop()", that would call into the right thing, no matter what it is. This allow for both runtime and compile time selection of what you're running. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
