On 01/06/2011 01:40 AM, Alexander Graf wrote:
On 06.01.2011, at 12:27, Zachary Amsden wrote:
On 01/06/2011 12:34 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsden<zamsden@xxxxxxxxxx>:
Use an MSR to allow "soft" migration to hosts which do not support
TSC trapping. Rather than make this a required element of any
migration protocol, we allow the TSC rate to be exported as a data
field (useful in its own right), but we also allow a one time write
of the MSR during VM creation. The result is that for the common
use case, no protocol change is required to communicate TSC rate
to the receiving host.
This allows administrative tools to configure migration policy
as they see appropriate. Rather than dictate this policy with the
KVM implementation, we properly allow migration to hosts which both
do and do not support setting of the TSC rate on the receiving end.
If it is wished to not support migration to a host which lacks
support for the TSC rate feature, that can be coordinated externally.
Isn't there a real hw equivalent of such a register? It might make more sense to just implement that then.
Unfortunately, no.
Bleks. I couldn't find anything in AMD documentation either. Intel documentation is usually hard to find and incomplete anyways, so maybe something's hiding there - but if it's hidden so well it's no use to implement either.
While it makes perfect logical sense to us software people, from a
hardware perspective it is ridiculous. There is no signal input to the
processor which can be counted and returned by a "CPU frequency MSR".
The CPU frequency is simply what the CPU is clocked at. And you can't
burn it onto the die (think of overclocking), unless you have your own
internal reference oscillator.
No, a CPU frequency MSR is impossible to implement sensibly in hardware
because
1) if you have an internal clock, you have cross-CPU drift and can't
easily share a common bus.
2) if you have an external clock, you have no way to measure the
frequency of it without an internal reference, which again will vary,
leading to different measured frequency on each CPU.
The only thing that sort of makes sense is a one-time writable MSR that
is programmed by the BIOS to return the CPU frequency, as retrieved from
the chipset. This is merely a convenience for software people who can't
be bothered to query the chipset directly or measure against a reference
clock.
So as much as we'd like it, it really does make little sense from a
hardware perspective.
Zach
--
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
