From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFlAp-0001qm-Kz for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:16:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFlAk-0000aM-0b for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:16:03 -0400 Received: from david.siemens.de ([192.35.17.14]:28461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFlAj-0000aH-Nf for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:15:57 -0400 Message-ID: <4E9C0E6C.2070809@siemens.com> Date: Mon, 17 Oct 2011 13:15:56 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E9C09E7.2010106@redhat.com> In-Reply-To: <4E9C09E7.2010106@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: Avi Kivity Cc: Alex Williamson , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" 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. > >> Moreover, >> different architecture or accelerators may want to overload the delivery >> handler. >> >> Therefore, this commit introduces a delivery hook that is called by the >> MSI/MSI-X layer when devices send normal messages, but also on spurious >> deliveries that ended up on the APIC MMIO handler. Our default delivery >> handler for APIC-based PCs then dispatches between real MSIs and other >> DMA requests that happened to take the MSI patch. > > 'path' > >> >> -static void apic_send_msi(target_phys_addr_t addr, uint32_t data) >> +void apic_deliver_msi(MSIMessage *msg) > > In general, it is better these days to pass small structures by value. OK, will adjust this. > > > 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). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux