From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: KVM in-kernel APIC update Date: Thu, 5 Apr 2007 12:39:33 +0200 Message-ID: <20070405103933.GA8936@elte.hu> References: <46128F80.BA47.005A.0@novell.com> <46135686.4090905@qumranet.com> <20070404201205.GC6070@elte.hu> <46149B7C.5020004@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: Content-Disposition: inline In-Reply-To: <46149B7C.5020004-atKUWr5tajBWk0Htik3J/w@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 * Avi Kivity wrote: > - *pic in kernel: most effort, easiest irq synchronization. Interface > is pic/ioapic pin level, plus a topology description that userspace > uses to tell the hardware how the pins are connected (logically > required, but practically not). yeah, that variant is the right way to do it. Note that this also paves the way for possible future PIC hardware virtualization features like the CPU directly injecting an external IRQ vector to the guest [without trapping out to the hypervisor]. Interrupt handling fundamentally belongs into the kernel, be that the host or the guest. (User-space abstractions in the PIC space make little sense and i know of none.) 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