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

Dong, Eddie
2007-08-05T10:56:57Z

Avi Kivity wrote:
> 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.
>
>
Got it, so we will go with only single pending irq case.
Eddie