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. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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
