From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: QEMU PIC indirection patch for in-kernel APIC work Date: Wed, 04 Apr 2007 19:05:37 +0300 Message-ID: <4613CCD1.2070702@qumranet.com> References: <4613BF07.50606@qumranet.com> <8FFF7E42E93CC646B632AB40643802A8025B9580@scsmsx412.amr.corp.intel.com> <64F9B87B6B770947A9F8391472E032160B318E96@ehost011-8.exch011.intermedia.net> <4613C9EE.5030600@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Anthony Liguori Return-path: In-Reply-To: <4613C9EE.5030600-rdkfGonbjUSkNkDKm+mE6A@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 Anthony Liguori wrote: > >> >> This pushes towards in kernel apic too. Can't see how we avoid it. >> > > Does it really? IIUC, we would avoid TPR traps entirely and would > just need to synchronize the TPR whenever we go down to userspace. > It's a bit more complex than that, as userspace would need to tell the kernel the highest priority pending interrupt so that it can program the hardware to exit when an interrupt is ready. However I agree with you that in principle we could split the apic emulation between kvm and qemu, even with this featurette. -- 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