From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: QEMU PIC indirection patch for in-kernel APIC work Date: Wed, 04 Apr 2007 11:48:13 -0500 Message-ID: <4613D6CD.6060209@codemonkey.ws> References: <4610A6A9.BA47.005A.0@novell.com> <46134B74.1080004@qumranet.com> <4613B438.60107@codemonkey.ws> <4613B89F.8090806@qumranet.com> <4613BC6B.1070708@codemonkey.ws> <4613BF07.50606@qumranet.com> <4613C993.9020405@codemonkey.ws> <4613CC01.1090500@qumranet.com> <4613CDB2.4000903@codemonkey.ws> <64F9B87B6B770947A9F8391472E032160B318ED4@ehost011-8.exch011.intermedia.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , Avi Kivity To: Dor Laor Return-path: In-Reply-To: <64F9B87B6B770947A9F8391472E032160B318ED4-yEcIvxbTEBqsx+V+t5oei8rau4O3wl8o3fe8/T/H7NteoWH0uzbU5w@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 Dor Laor wrote: >>>> If we do this, then we can probably just handle the TPR as a special >>>> case anyway and not bother returning to userspace when the TPR is >>>> updated through MMIO. That saves the round trip without adding >>>> emulation complexity. >>>> >>> That means the emulation is split among user space and kernel. Not >>> nice. One of the advantages of moving the entire thing is that it is >>> at least clearly defined. >>> >> It still exists in userspace. Having the code duplication (especially >> when it's not the same code base) is unfortunate. Plus, it complicates >> save/restore/migration since now some device state is in the kernel. >> > It > >> further complicates things if you want to make sure that KVM saved >> images are loadable in QEMU (you have to make sure that the device >> > state > >> is identical for the kernel and userspace). Special casing the TPR >> emulation seems like the lesser of two evils to me. >> >> > > There are still some nasty issues that caused by running apic in qemu: > - If you have a PV driver that issued an irq and now it needs another > one, > You cannot really be sure if the first one was injected. You can hold > > extra state and follow irq injection from qemu but this is ugly. > - You have to keep sync of tpr and irq injection: suppose apic needs to > > inject an irq, it pops it from the irr and tries to inject it. If it > is > done while the VM is in interrupt window closed or irq disables it > will > no happen instantly. When the irq would really be injected the tpr > might > be different, causing windows irq-not-less-or-equal BSOD. > This is especially true for injecting several irq at once. > > Keeping the apic in the kernel simplifies this with the cost of > maintaining an apic/pic implementation. > Hrm, this is definitely starting to sound like a PITA to deal with. Maybe in-kernel platform devices are unavoidable :-/ > Do you know why Xen guy choose of implementing it in Xen? Why didn't > they rip Qemu implementation? > I believe it's based on the QEMU implementation although it's evolved quite a bit. Jun can probably provide a better answer. Regards, Anthony Liguori > >> Regards, >> >> Anthony Liguori >> > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV