Re: preview of in kernel irqchip live migration support

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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/