From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM in-kernel APIC update Date: Thu, 05 Apr 2007 10:11:44 +0300 Message-ID: <4614A130.2000805@qumranet.com> References: <46128F80.BA47.005A.0@novell.com> <20070404203235.GA11369@elte.hu> <4613D0CE.BA47.005A.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Gregory Haskins Return-path: In-reply-to: <4613D0CE.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@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 Gregory Haskins wrote: >>>> On Wed, Apr 4, 2007 at 4:32 PM, in message <20070404203235.GA11369-X9Un+BFzKDI@public.gmane.org>, >>>> > Ingo Molnar wrote: > >>> My current thoughts are that we at least move the IOAPIC into the >>> kernel as well. [...] >>> >> yes. And then do the final 10% move of handling the i8529A in KVM too. >> > > Hi Ingo, > We are in full agreement on this point, and has been my preferred model from the beginning. The only issue with this approach is that it requires a fairly disruptive patch to QEMUs "pic_set_irq()" feature which many people have drawn exception to so far. (In case you weren't following from the beginning, its the "QEMU PIC indirection patch...." thread). > You can hack it with if (use_kvm) { ... } (or, more likely, use_kvm_platform_/ > If we dont care about supporting "--no-kvm" anymore, this problem becomes trivially easy.....we can just link in a different pic module into QEMU and be done with it. The problem as I see it is that we really have a lot of value in being able to switch between kvm and pure qemu mode via --no-kvm, especially for debugging. Therefore, IMHO we need to be able to dynamically switch between PIC emulation code. > > -no-kvm is critical, it's an important debugging tool. Also keeping emulation in qemu is important for <= 2.6.21 (or maybe 22) users, which will not have the in-kernel platform devices. > If we *do* want to go with this model, *and* we decide that the approach I have taken with QEMU is a reasonable way to do it, then I would suggest we go about it by getting the patch accepted in QEMU upstream. I would gladly take on this duty if we all agree this is the right approach. > I think getting the patch in is beneficial. Perhaps after re-review in light of all the discussion. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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