From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gregory Haskins" Subject: Re: KVM in-kernel APIC update Date: Wed, 04 Apr 2007 13:56:58 -0400 Message-ID: <4613A090.BA47.005A.0@novell.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> <4613E3CB.6000904@qumranet.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: "Avi Kivity" Return-path: In-Reply-To: <4613E3CB.6000904-atKUWr5tajBWk0Htik3J/w@public.gmane.org> Content-Disposition: inline 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 >>> On Wed, Apr 4, 2007 at 1:43 PM, in message <4613E3CB.6000904-atKUWr5tajBWk0Htik3J/w@public.gmane.org>, Avi Kivity wrote: > 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. I believe we would be ok here. The current code uses a similar model for edge/level, where edge simply ignores *value*, and level uses non-zero value as "assert" and 0 as "deassert". As far as the pin/vector mapping, that would be taken care of by the programming of the IOAPIC by the BIOS/OS. > pci is level triggered, so maybe the guests just handle the inaccuracy. > Good point. I'm not sure how this works today. Perhaps we just get lucky that nothing checks the IRR in the IOAPIC coupled with a bug in the IOAPIC model that an APIC message is sent out even if the interrupt is not acknowledged. It would explain why it works today, anyway. Either way, I would like to get this modeled "right" this go-round, so the point is moot. -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