From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC][PATCH 11/45] msi: Factor out delivery hook Date: Mon, 17 Oct 2011 12:56:39 +0200 Message-ID: <4E9C09E7.2010106@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alex Williamson , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org, "Michael S. Tsirkin" To: Jan Kiszka Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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? > 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. Not sure what the gain is from intercepting the msi just before the stl_phys() vs. in the apic handler. -- error compiling committee.c: too many arguments to function