From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH 11/45] msi: Factor out delivery hook Date: Mon, 17 Oct 2011 13:29:08 +0200 Message-ID: <4E9C1184.4040908@siemens.com> References: <4E9C09E7.2010106@redhat.com> <4E9C0E6C.2070809@siemens.com> <4E9C100A.2070705@redhat.com> 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: Avi Kivity Return-path: In-Reply-To: <4E9C100A.2070705@redhat.com> 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 2011-10-17 13:22, Avi Kivity wrote: > 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. See my other mail. > > >> >>> >>> >>> 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. Right, but that's the slow path (which is still handled - on x86 via the MMIO region the APIC still maintains). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux