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

Avi Kivity
2007-08-05T10:54:33Z

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.