On 02/09/2011 07:29 PM, Joerg Roedel wrote:
Hi Avi, Marcelo,
here is the patch-set to implement the TSC-scaling feature of upcoming
AMD CPUs. When this feature is supported the CPU provides a new MSR
which holds a multiplier for the hardware TSC which is applied on the
value rdtsc[p] and reads of MSR 0x10. This feature can be used to
emulate a given tsc frequency for the guest.
Patch 1 is not directly related to this patch-set because it only fixes
a bug which prevented me from testing these patches. In fact it fixes
the same bug Andre sent a patch for. But after the discussion about his
patch he told me to just post my patch and thus here it is.
Questions:
- the tsc multiplier really is a multiplier, right? Not an addend that
is added every cycle.
So
wrmsr(TSC, 1e9)
wrmsr(TSC_MULT, 2.0000)
t = rdtsc()
will return about 2e9, not 1e9 + 2*(time to execute the code snippet) ?
- what's the cost of wrmsr(TSC_MULT)?
There are really two ways to implement this feature. One is fully
generic, like you did. The other is to implement it at the host level -
have a sysfs file and/or kernel parameter for the desired tsc frequency,
write it once, and forget about it. Trust management to set the host
tsc frequency to the same value on all hosts in a migration cluster.
The advantages of the the simpler implementation are, well, that it's
simpler, and second that it avoids two wrmsrs per exit. We could
combine both implementations, and have
if (guest_mult != host_mult)
wrmsr(TSC_MULT, guest_mult)
etc. But I'd like to understand if there are additional motivations for
per-guest tsc frequency.
--
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
