From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCv1Z-0004ns-DQ for qemu-devel@nongnu.org; Wed, 28 Mar 2012 11:43:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCv1W-0001pc-Nh for qemu-devel@nongnu.org; Wed, 28 Mar 2012 11:43:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5493) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCv1W-0001pT-FQ for qemu-devel@nongnu.org; Wed, 28 Mar 2012 11:42:58 -0400 Date: Wed, 28 Mar 2012 17:43:11 +0200 From: "Michael S. Tsirkin" Message-ID: <20120328154309.GB20176@redhat.com> References: <4F72BA12.2080309@web.de> <20120328094459.GB6194@redhat.com> <4F72DEE3.4050704@siemens.com> <20120328104731.GC6194@redhat.com> <4F72F0FE.2010405@siemens.com> <20120328113139.GG6194@redhat.com> <4F72F7AF.4020309@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F72F7AF.4020309@siemens.com> Subject: Re: [Qemu-devel] [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Marcelo Tosatti , Avi Kivity , "kvm@vger.kernel.org" , qemu-devel On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote: > On 2012-03-28 13:31, Michael S. Tsirkin wrote: > >>>>> Also, how would this support irqfd in the future? Will we have to > >>>>> rip it all out and replace with per-device tracking that we > >>>>> have today? > >>>> > >>>> Irqfd and kvm device assignment will require additional interfaces (of > >>>> the kvm core in QEMU) via which you will be able to request stable > >>>> routes from such sources to specified MSIs. That will be widely > >>>> orthogonal to what is done in these patches here. > >>> > >>> Yes but not exactly as they will conflict for resources, right? > >>> How do you plan to solve this? > >> > >> As done in my original series: If a static route requires a pseudo GSI > >> and there are none free, we simply flush the dynamic MSI routes. > > > > Right. So static routes take precedence. This means that in effect > > we will have two APIs in qemu: for fast MSIs and for slow ones, > > the advantage of the slow APIs being that they are easier to use, > > right? > > We will have two APIs depending on the source of the MSI. Special > sources are the exception while emulated ones are the majority. And for > the latter we should try very hard to keep things simple and clean. > > Jan I assume this means yes :) So how about we replace the hash table with a single GSI reserved for this purpose, and use that for each interrupt? This will work fine for slow paths such as hotplug controller, yes it will be slow but *predictably* slow. Fast path will use static GSIs like qemu-kvm does. > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux