Ian Jackson wrote:
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.
I thing it makes sense for you to have multiple vcpus -- that is
multiple CPUState objects. You can still have just one thread (which
would be the iothread in kvm's terminology).
So:
tcg - multiplexes all vcpus and io on one thread
kvm - iothread + per-vcpu thread
xen - iothread, vcpus scheduled by hypervisor
tcg also ought to move to an iothread model, so it can take advantage of
multicore for things like display updates. For x86-on-x86, it may even
be possible to have vcpus running in parallel (with some kind of
shared/exclusive lock on softmmu).
--
error compiling committee.c: too many arguments to function
--
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
