Gabe Black wrote:
It would also be interesting to hear how you use kvm.
Ultimately, we'd like to use KVM for at least two things. The first is
as a way to fast forward simulations to the portion of interest before
switching into something slower that can collect interesting statistics
and accurately simulate performance. Our immediate goal on our way to
that is to get a CPU based around KVM to boot Linux while hooked into
our device models. We're very early in the process, but one challenge
I'm anticipating is being able to pull the local APIC out of the virtual
CPU and into M5 so that we can coordinate IPIs, etc., ourselves.
Since we support live migration, it should be doable. Tricky though.
The other thing we'd like to do is to use KVM as a golden model to
verify our correctness against. To do that, we'll probably need to make
significant progress on the above, and then also find a mechanism to
make each CPU advance in very incremental and deterministic ways. Our
thought on that so far as been to set the TF bit in the guest and use
the #DB to exit back to the host. We expect there will be some gotchas
with this like hold off on mov to %ss, but if there would be any show
stopper problems please let us know.
It should work as long as the guest doesn't debug itself, I think. May
have problems with interrupts or NMIs.
--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
