From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: [PATCH 2/2] turn off kvmclock when resetting cpu Date: Tue, 4 May 2010 14:35:28 -0400 Message-ID: <1272998128-30384-3-git-send-email-glommer@redhat.com> References: <1272998128-30384-1-git-send-email-glommer@redhat.com> <1272998128-30384-2-git-send-email-glommer@redhat.com> Cc: avi@redhat.com, zamsden@redhat.com, mtosatti@redhat.com To: kvm@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62427 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760063Ab0EDSha (ORCPT ); Tue, 4 May 2010 14:37:30 -0400 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o44IbTwa021546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 May 2010 14:37:29 -0400 In-Reply-To: <1272998128-30384-2-git-send-email-glommer@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Currently, in the linux kernel, we reset kvmclock if we are rebooting into a crash kernel through kexec. The rationale, is that a new kernel won't follow the same memory addresses, and the memory where kvmclock is located in the first kernel, will be something else in the second one. We don't do it in normal reboots, because the second kernel ends up registering kvmclock again, which has the effect of turning off the first instance. This is, however, totally wrong. This assumes we're booting into a kernel that also has kvmclock enabled. If by some reason we reboot into something that doesn't do kvmclock including but not limited to: * rebooting into an older kernel without kvmclock support, * rebooting with no-kvmclock, * rebootint into another O.S, we'll simply have the hypervisor writing into a random memory position into the guest. Neat, uh? Moreover, I believe the fix belongs in qemu, since it is the entity more prepared to detect all kinds of reboots (by means of a cpu_reset), not to mention the presence of misbehaving guests, that can forget to turn kvmclock off. This patch fixes the issue for me. Signed-off-by: Glauber Costa --- qemu-kvm-x86.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c index 439c31a..4b94e04 100644 --- a/qemu-kvm-x86.c +++ b/qemu-kvm-x86.c @@ -1417,8 +1417,27 @@ void kvm_arch_push_nmi(void *opaque) } #endif /* KVM_CAP_USER_NMI */ +static int kvm_turn_off_clock(CPUState *env) +{ + struct { + struct kvm_msrs info; + struct kvm_msr_entry entries[100]; + } msr_data; + + struct kvm_msr_entry *msrs = msr_data.entries; + int n = 0; + + kvm_msr_entry_set(&msrs[n++], MSR_KVM_SYSTEM_TIME, 0); + kvm_msr_entry_set(&msrs[n++], MSR_KVM_WALL_CLOCK, 0); + msr_data.info.nmsrs = n; + + return kvm_vcpu_ioctl(env, KVM_SET_MSRS, &msr_data); +} + + void kvm_arch_cpu_reset(CPUState *env) { + kvm_turn_off_clock(env); kvm_arch_reset_vcpu(env); kvm_reset_mpstate(env); } -- 1.6.2.2