From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFnRu-0008UY-Lb for qemu-devel@nongnu.org; Mon, 17 Oct 2011 09:41:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFnRt-0006ed-FD for qemu-devel@nongnu.org; Mon, 17 Oct 2011 09:41:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFnRt-0006eW-7v for qemu-devel@nongnu.org; Mon, 17 Oct 2011 09:41:49 -0400 Message-ID: <4E9C3098.4080804@redhat.com> Date: Mon, 17 Oct 2011 15:41:44 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4E9C09E7.2010106@redhat.com> <4E9C0E6C.2070809@siemens.com> <20111017134135.GC6406@redhat.com> In-Reply-To: <20111017134135.GC6406@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Jan Kiszka , Alex Williamson , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" On 10/17/2011 03:41 PM, Michael S. Tsirkin wrote: > On Mon, Oct 17, 2011 at 01:15:56PM +0200, Jan Kiszka wrote: > > On 2011-10-17 12:56, Avi Kivity wrote: > > > On 10/17/2011 11:27 AM, Jan Kiszka wrote: > > >> So far we deliver MSI messages by writing them into the target MMIO > > >> area. This reflects what happens on hardware, but imposes some > > >> limitations on the emulation when introducing KVM in-kernel irqchip > > >> models. For those we will need to track the message origin. > > > > > > Why do we need to track the message origin? Emulated interrupt remapping? > > > > The origin holds the routing cache which we need to track if the message > > already has a route (and that without searching long lists) and to > > update that route instead of add another one. > > Hmm, yes, but if the device does stl_phys or something like this, > it won't work with irqchip, will it? And it should, ideally. Why not? it will fall back to the apic path, and use the local routing cache entry there. -- error compiling committee.c: too many arguments to function