From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFlHV-0008B8-3S for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:23:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFlHT-00021w-LV for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:22:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFlHT-00021o-76 for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:22:55 -0400 Message-ID: <4E9C100A.2070705@redhat.com> Date: Mon, 17 Oct 2011 13:22:50 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4E9C09E7.2010106@redhat.com> <4E9C0E6C.2070809@siemens.com> In-Reply-To: <4E9C0E6C.2070809@siemens.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: Jan Kiszka Cc: Alex Williamson , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" On 10/17/2011 01:15 PM, 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. Okay, having read more of the code I understand this better. The approach of providing an explicit cache entry, while more intrusive, is simpler (at least, without std::unordered_map). However you do need destructors for the cache to let the core know that it can't reference it anymore. > > > > > > > Not sure what the gain is from intercepting the msi just before the > > stl_phys() vs. in the apic handler. > > APIC is x86-specific, MSI is not. I think Xen will also want to make use > of this hook. I originally though of using it for the KVM in-kernel > models as well, but I will now establish a callback at APIC-level > (upstream will look differently from qemu-kvm in this regard). > But you still have to handle it the the platform interrupt controller (or whatever processes msi messages) since you can still DMA there. So you don't get away from doing it there anyway. -- error compiling committee.c: too many arguments to function