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 15:24:47 -0500 Message-ID: <4614098F.2030307@us.ibm.com> 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> <4613D001.3040606@qumranet.com> <20070404200112.GA6070@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Ingo Molnar Return-path: In-Reply-To: <20070404200112.GA6070-X9Un+BFzKDI@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 Ingo Molnar wrote: > * Avi Kivity wrote: > > >>> It still exists in userspace. Having the code duplication >>> (especially when it's not the same code base) is unfortunate. >>> >> This remains true. >> > > but it's the wrong argument. Of course there's duplicate functionality, > and that's _good_ because it represents choice. KVM _itself_ is > duplicate functionality of qemu in a way. So why move the lapic/PIC > handling to the kernel? Because it's alot cleaner to do device emulation > there and PV drivers get significantly easier to do. But why is it a good thing to do PV drivers in the kernel? You lose flexibility and functionality to gain performance. Really, it's more about there not being good enough userspace interfaces to do network IO. > The lapic/PIC code > should also be available in Qemu for OSs that dont have KVM-alike > support in the kernel. > > and while today most of the performance advantages of moving the PIC > into the kernel are masked by the high cost of VM exits, in the future > the effect will be more marked, as the relative cost of piggybacking out > to qemu increases. > > I can see the value in doing certain things in Qemu, but i cannot see > _at all_ the value of handling say the PIT in Qemu. Just look at the > Qemu PIT/timers code quality in Qemu for a change ... it's a huge ugly > mess of lots of #ifdefs, ineffective handling of /dev/rtc, linear list > walking, signal overhead, etc., etc. All of that resulting in 10-15% of > 'idle' overhead of KVM+qemu when it runs a Linux guest. On the other > side, in the kernel it's most natural to do timers and to emulate > hardware, because the kernel has _precise_ knowledge about the > platform's capabilities. > Yeah, I think this is a good point. If we're going to push the APIC into the kernel, we might as well put the PIT there too. The timing stuff is an absolute mess in QEMU since it wants to get a fast high res clock but isn't aware of things like CPU migration. I'm pretty sure that if you are on an SMP host, some bad things can happen with the QEMU timer code since it relies on the rdtsc. Regards, Anthony Liguori > Ingo > > ------------------------------------------------------------------------- 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