Am 06.01.2011 um 11:10 schrieb Zachary Amsden<zamsden@xxxxxxxxxx>:
Reasons to trap the TSC are numerous, but we want to avoid it as muchWhen migrating, the implementation could switch from non-trapped to trapped, making it less attractive. The guest however does not get notified about this change. Same for the other way around.
as possible for performance reasons.
We provide two conservative modes via modules parameters and userspace
hinting. First, the module can be loaded with "tsc_auto=1" as a module
parameter, which turns on conservative TSC trapping only when it is
required (when unstable TSC or faster KHZ CPU is detected).
For userspace hinting, we enable trapping only if necessary. Userspace
can hint that a VM needs a fixed frequency TSC, and also that SMP
stability will be required. In that case, we conservatively turn on
trapping when it is needed. In addition, users may now specify the
desired TSC rate at which to run. If this rate differs significantly
from the host rate, trapping will be enabled.
There is also an override control to allow TSC trapping to be turned on
or off unconditionally for testing.
We indicate to pvclock users that the TSC is being trapped, to allow
avoiding overhead and directly using RDTSCP (only for SVM). This
optimization is not yet implemented.
Would it make sense to add a kvmclock interrupt to notify the guest of such a change?