From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: u <-> k cross migration and IDT_Vectoring save/restore Date: Sun, 05 Aug 2007 13:54:33 +0300 Message-ID: <46B5AC69.4020908@qumranet.com> References: <10EA09EFD8728347A513008B6B0DA77A01E0094F@pdsmsx411.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: "Dong, Eddie" Return-path: In-Reply-To: <10EA09EFD8728347A513008B6B0DA77A01E0094F-wq7ZOvIWXbNpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/