heads up: guest reset after migration using --enable-kvm

Message ID m363b2bz6s.fsf@neno.mitica
State Superseded
Headers show

Commit Message

Juan Quintela Sept. 28, 2009, 8:18 p.m.

As I spent too much time last week tracking this bug, just to let you
know.  If you run qemu --enable-kvm, and you do migration or loadvm from
the command line, guest just loads correctly and then reset with a
triple fault.

Problem happens if you are using a 2.6.30.x kernel, this is going to be
reverted  on the next stable kernel.  2.6.31 suffers the same problem.

qemu-kvm.git works here, problem is with qemu --enable-kvm.

If you do loadvm from the command monitor after having run another
guests, things work as expected.

Later, Juan.
This reverts commit 6c20e1442bb1c62914bb85b7f4a38973d2a423ba.

To my understanding, it became obsolete with the advent of the more
robust check in mmu_alloc_roots (89da4ff17f). Moreover, it prevents
the conceptually safe pattern

 1. set sregs
 2. register mem-slots
 3. run vcpu

by setting a sticky triple fault during step 1.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
(cherry picked from commit dc7e795e3dd2a763e5ceaa1615f307e808cf3932)


diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3d36045..2e0b363 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4118,13 +4118,7 @@  int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
 	vcpu->arch.cr2 = sregs->cr2;
 	mmu_reset_needed |= vcpu->arch.cr3 != sregs->cr3;
-	down_read(&vcpu->kvm->slots_lock);
-	if (gfn_to_memslot(vcpu->kvm, sregs->cr3 >> PAGE_SHIFT))
-		vcpu->arch.cr3 = sregs->cr3;
-	else
-		set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
-	up_read(&vcpu->kvm->slots_lock);
+	vcpu->arch.cr3 = sregs->cr3;
 	kvm_set_cr8(vcpu, sregs->cr8);