Re: u <-> k cross migration and IDT_Vectoring save/restore

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

Dong, Eddie wrote:
> Avi:
> 	Basically with those patches applied so far, we can do k<->k, u
> <->u and k->u live migration for typical case, the u->k migration has
> bug so far which is still debuging. 
> 	But I am thinking about the corner case (pending irq) for cross
> migration, i.e. pending irq in valid IDT_Vectoring of kernel irqchip and
> those in interrupt_bitmap of user level case.  In most case, there are
> no pending irqs, that is fine for us. In some case if there is a pending
> irq, cross migration need to convert between them which may be not
> feasible.
> 	In k->u case,  we can just convert the IDT_vectoring indicated
> pending irq (single vector) to a interrupt_bitmap, but vice versa may
> not be true since user level case may have multiple pending irqs in
> theory though rare.  In that case u->k cross migration may fail since we
> don't know this vectored irq comes from PIC or APIC and thus unable to
> push back to PIC/APIC device model. If there is only one pending irq in
> interrupt_bitmap, we can simply convert it to IDT_Vectoring 
> 	BTW, multiple pending IRQs in interrupt_bitmap has potential
> architectural issue even in pure user level case due to premature
> IRR->ISR convert in PIC/APIC device model as we discussed.
>
> 	If above limitation is fine, we can use interrupt_bitmap in
> SREGS data structure to carry the pending irq for kernel level too.
> 	Any opinion?
> thx,eddie
>   

Userspace will never set more than one bit in the pending bitmap, 
because it needs to inspect the tpr before injecting an interrupt.  As 
to converting the single bit to IDT_Vectoring, I think this is very 
natural since the pending bitmap maps to IDT_Vectoring much more closely 
than to the apic or pic (as it is after apic and pic processing).

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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/