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? 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. > 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). > Same page :-) 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
