From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM in-kernel APIC update Date: Wed, 04 Apr 2007 16:40:43 -0500 Message-ID: <46141B5B.1050105@us.ibm.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). > > If we dont care about supporting "--no-kvm" anymore, this problem becomes trivially easy..... No, this would be a big mistake. We'll just end up with another qemu-dm. > 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. > > 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 you should post the patch on qemu-devel if for nothing else to begin the discussion. Regards, Anthony Liguori > >> for PV/accel drivers we dont need any extra ACPI enumeration - the >> hypercall API is good enough to connect to the hypervisor, and i suspect >> all guest OSs we care about allow drivers to allocate an IRQ vector for >> a new device, without having that device enumerated in ACPI. >> > > If you know how to do this in Linux, please share! I was looking for this earlier and came up empty handed. All I could find was the places where the PCI/MP/ACPI type things assigned vectors to devices they new about. It's probably "operator-ignorance" ;) > > Regards, > -Greg > > > > ------------------------------------------------------------------------- > 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 > _______________________________________________ > kvm-devel mailing list > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > ------------------------------------------------------------------------- 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