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