>This patch is only for idea collection so far. >The dilemma is that how to export the pic/IOAPIC/apic state data >structure to user and make sure it has same/similar structure in user >level. >Otherwise a >convert is a must and we must maintain the converter.
IMHO there is no need of supporting migration from/to kernel/user. The main point of maintaining pic/apic/ioapic in to test our implementation against a stable working implementation. Once the kernel implementation will be stable there is no need to support the userspace. btw: Why don't you use the standard qemu's register_savev//loadvm for saving the state? I think it's better than adding code in migration.c >With this, PIC only guest can do live migration successfully. We can >extend APIC side seamlessly. > >BTW, there is potential issue in IDT_Vectoring. The fix IMO is to retry >vm_stop at user level to make sure no pending IDT_vectoring. Isn't it possible to serialize the pending IDT_vectoring too? If the answer is no, the solution is to add an ioctl that will test the pending statis in migration.c::migrate_check_convergence. If it's pending, add another migrate_write loop iteration. > >Pls comments. Also I will temply off this week, Qing He may continue. > >Thx,eddie ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
