On 06/22/2010 01:10 PM, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 13:06 +0300, Avi Kivity wrote:
You have a set of MSRs for real hardware (actually several sets)
discoverable by cpuid bits. You have another set of MSRs, using other
indexes, discoverable by more CPUID bits.
The new MSR indexes will always #GP on real hardware, but will be
trapped and serviced by kvm. In effect kvm will pretend to have a
hardware-like PMU but done according to its own specifications.
So what's the point?
We already have infrastructure for save/restore around MSRs. They are
state-based (as opposed to function-based hypercalls), so it's easy to
live migrate by copying the MSR values.
I thought the whole MSR interface thing was purely
to let other-o$ play with the PMU, but if you move it around like that
and make it KVM specific, nobody will find it...
Other-os support will be achieved by emulating an existing interface.
--
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
