On Tue, 2007-07-10 at 22:08 +0800, Dong, Eddie wrote: > > I don't think live migration is particularly difficult. You > > need a APIs > > to read and write the PIC+LAPIC states, and you write the > > state into the > > This is partily true party not.
I agree with Avi here. The system is already set up to understand that there are userspace and kernel components that need to save state for a migration. Its only a matter of adding any new elements to the set. > Like what did in Xen, a live migration > in kernel side need to consider not only device state, but also cpu > state. Right, and this is already true in KVM as well. > Especially when live migration happens when a VCPU get valid > IDT_Vectoring, we need to save all various cpu states, (What current > code did to "push back" an vector can't service us with apic in kernel), > and we have NMI state to save too. I had already solved these types of issues neatly in the lapic branch, so perhaps you can model a solution from that (at least in spirit). For instance, the irq.deferred source has the IDT_Vectoring state, irq.pending has the vcpu interrupt state (NMI, EXTINT, etc), kvm->isa_int has the PIC state, and vcpu->apic has the lapic state, etc. I never got to adding the live-migration support, but if I had I would have added elements to the data set for these components (vcpu->irq, vcpu->apic, kvm->isa_irq) in addition to whats already saved (most of the rest of the vcpu state). ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
