Am 14.09.2010 11:27, Avi Kivity wrote:
On 09/14/2010 11:10 AM, Jan Kiszka wrote:Looks like that's the case on first glance at the apic state.
Am 20.08.2010 10:07, Zachary Amsden wrote:Most likely, time went backwards, and some 'future - past' calculation
When CPUs with unstable TSCs enter deep C-state, TSC may stopFor yet unknown reason, this commit breaks Linux guests here if they are
running. This causes us to require resynchronization. Since
we can't tell when this may potentially happen, we assume the
worst by forcing re-compensation for it at every point the VCPU
task is descheduled.
Signed-off-by: Zachary Amsden<zamsden@xxxxxxxxxx>
---
arch/x86/kvm/x86.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7fc4a55..52b6c21 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1866,7 +1866,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
}
kvm_x86_ops->vcpu_load(vcpu, cpu);
- if (unlikely(vcpu->cpu != cpu)) {
+ if (unlikely(vcpu->cpu != cpu) || check_tsc_unstable()) {
/* Make sure TSC doesn't go backwards */
s64 tsc_delta = !vcpu->arch.last_host_tsc ? 0 :
native_read_tsc() - vcpu->arch.last_host_tsc;
started with only a single VCPU. They hang during boot, obviously no
longer receiving interrupts.
I'm using kvm-kmod against a 2.6.34 host kernel, so this may be a side
effect of the wrapping, though I cannot imagine how.
Anyone any ideas?
resulted in a negative sleep value which was then interpreted as
unsigned and resulted in a 2342525634 year sleep.
Does your guest use kvmclock, tsc, or some other time source?A kernel that has kvmclock support even hangs in SMP mode. The others
pick hpet or acpi_pm. TSC is considered unstable.