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
-------------------------------------------------------------------------
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/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
