Chris Lalancette wrote: > All, > Attached is a patch that fixes the first (of at least a couple) migration > problem that I am running into. Basically, using the setup I described in my > last post, I was always getting "Disabling IRQ #11" once the guest reached the > destination side, and then no further activity. Dumping the APIC on both the > source and destination side revealed something interesting: > > >
[...] > You'll notice that the base_address and irr are completely bogus on the > destination side. Although KVM_CREATE_IRQCHIP does the right thing on the > destination side when first creating the "incoming" guest, the base_address > and > other fields get blown away with bogus data during the restore. The attached > patch fixes this by only restoring the bits that we know were saved on the > source side (i.e. what's in qemu/hw/apic.c:ioapic_save()). > Excellent catch, but the fix is wrong. Instead of partially restoring the ioapic state in the kernel, you should fully save it in qemu. This is a trap that many fall into: considering kvm and qemu as one entity and making sure they work well together. We need to make sure that kvm and libkvm are useful for other userspace programs as well. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
