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

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

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> 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
>>     
>
> I didn't look into detail of them in user level. But can TPR checking
> guarantee
> there is no multiple injection? 

It's the other way round:  the code injects interrupts one at a time in 
order to be able to check the tpr in user space (the whole 
pending_interrupts thing is a bug -- it's impossible to queue interrupts 
at that level because of the tpr).


> An asynchronize device model can inject
> an
> higher irq after the previous one.
> Even in synchronize model, if a previous irq fails to inject with
> IDT_vectoring valid,
> and get push back, a higher irq can again get injected.
>
>   
The code guarantees that we won't inject an interrupt until after the 
previous one was accepted, but I think it doesn't handle failures to 
inject well.


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