From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM in-kernel APIC update Date: Wed, 04 Apr 2007 20:43:39 +0300 Message-ID: <4613E3CB.6000904@qumranet.com> References: <46128F80.BA47.005A.0@novell.com> <46135686.4090905@qumranet.com> <46138A98.BA47.005A.0@novell.com> <4613D736.1080207@qumranet.com> <4613959F.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: <4613959F.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: > Agreed. I was thinking that the interface for the "IOAPIC in kernel" model would look something like the way the pic_send_irq() function looks, except it would also convey BUS/IOAPIC id. > > so: kvm_inject_interrupt(int bus, int pin, int value); > > and the "kvmpic" driver would currently translate as bus = 0 (giving us IRQ0-23). E.g. > > kvmpic_send_irq(int irq, int value) > { > kvm_inject_interrupt(0, irq, value); > } > With appropriate modeling of edge vs level triggered, and translation of pin to vector, yes. > > >> Everything should keep working, that is a must. We just need the >> interfaces to follow the hardware faithfully. The issue with the ioapic >> eoi is worrying me performance wise, though; it looks like we need to >> push the ioapic too if we are to have no- compromise performance on >> unmodified OSes. >> > > Not sure if this will make you feel better, but it appears as though both the QEMU and the in-kernel model that I inherited don't accurately support IOAPIC EOI already. From that you can infer that there must not be any level-sensitive interrupts in use today. Since the system seems to only have the legacy ISA model (which dictates edge triggers, IIRC), this makes sense. However, if we want to support level triggers in the future, we will have to address this. I would be uncomfortable designing something that doesn't take the IOAPIC EOI into account, even if its not immediately used. > > pci is level triggered, so maybe the guests just handle the inaccuracy. >> For unmodified guests, use the existing pci irq routing. I certainly >> wouldn't want to debug anything else. For modified guests, there's no >> real problem. >> > > Ill take your word for it ;) I spent a few minutes looking through the linux kernel trying to figure out how to get a hint about a free vector without assigning one statically in the header files and came up empty handed. Im sure there is a way (or maybe static is ok?). > > No idea really, but the paravirt_ops stuff probably provides the right hooks. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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