From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWZmN-0002wa-Lk for qemu-devel@nongnu.org; Mon, 21 May 2012 17:04:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWZmL-0001jb-Nv for qemu-devel@nongnu.org; Mon, 21 May 2012 17:04:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWZmL-0001jM-FT for qemu-devel@nongnu.org; Mon, 21 May 2012 17:04:33 -0400 Date: Tue, 22 May 2012 00:04:36 +0300 From: "Michael S. Tsirkin" Message-ID: <20120521210435.GE17031@redhat.com> References: <4FBA3F8B.9060103@siemens.com> <20120521173358.GA13690@redhat.com> <4FBA9071.3010204@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FBA9071.3010204@siemens.com> Subject: Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Alex Williamson , Marcelo Tosatti , qemu-devel , Avi Kivity On Mon, May 21, 2012 at 03:58:57PM -0300, Jan Kiszka wrote: > On 2012-05-21 14:34, Michael S. Tsirkin wrote: > > On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote: > >> Add a PCI IRQ path discovery function that walks from a given device to > >> the host bridge, returning the IRQ number that is reported to the > >> attached interrupt controller. For this purpose, another PCI bridge > >> callback function is introduced: map_host_irq. It is so far only > >> implemented by the PIIX3, other host bridges can be added later on as > >> required. > >> > >> Will be used for KVM PCI device assignment. > >> > >> Signed-off-by: Jan Kiszka > > > > interrupt injection is data path even for emulated devices. > > So instead of special casing device assignment I would like to see all > > devices converted to an API that caches irqs. > > > > This will likely mean that we can maintain the final > > irq as part of the pci device structure, and > > this api will simply return it. > > Yep, I definitely agree. It's just that such a design has to please even > more users than PCI devices, thus will likely take longer to settle than > the device assignment effort. Therefore I decided to rush forward with > an intermediate approach first. > > Jan I think it's easy, will try to do it soon. > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux