Dor Laor wrote: >> 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. > >
No, we have to support 2.6.22 and 2.6.23 which don't have in-kernel apic. We need to avoid multiple migration (and state save) formats. > >> 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. > IDT_vectoring is am implementation detail, we don't want to expose it in the migration protocol because it ties us up. Best to avoid it. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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
