From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RH9uv-0003pD-3j for qemu-devel@nongnu.org; Fri, 21 Oct 2011 03:53:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RH9uu-0000nT-4Q for qemu-devel@nongnu.org; Fri, 21 Oct 2011 03:53:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RH9ut-0000l3-SF for qemu-devel@nongnu.org; Fri, 21 Oct 2011 03:53:24 -0400 Date: Fri, 21 Oct 2011 09:54:27 +0200 From: "Michael S. Tsirkin" Message-ID: <20111021075427.GB10633@redhat.com> References: <20111018184024.GB8322@redhat.com> <4E9DD56A.2010704@web.de> <20111018214006.GB7216@redhat.com> <4E9DFA1D.4050905@web.de> <20111019005631.GA10634@redhat.com> <4E9E712C.8000905@web.de> <20111019090305.GA25794@redhat.com> <4E9EB1AF.7090406@siemens.com> <20111020220201.GA25588@redhat.com> <4EA11A96.20202@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA11A96.20202@siemens.com> Subject: Re: [Qemu-devel] [RFC][PATCH 28/45] qemu-kvm: msix: Drop tracking of used vectors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Alex Williamson , Marcelo Tosatti , Avi Kivity , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" On Fri, Oct 21, 2011 at 09:09:10AM +0200, Jan Kiszka wrote: > On 2011-10-21 00:02, Michael S. Tsirkin wrote: > >>> Yes. But this still makes an API for acquiring per-vector resources a requirement. > >> > >> Yes, but a different one than current use/unuse. > > > > What's wrong with use/unuse as an API? It's already in place > > and virtio calls it. > > Not for that purpose. > It remains a useless API in the absence of KVM's > requirements. > Sorry, I don't understand. This can acquire whatever resources necessary. It does not seem to make sense to rip it out only to add a different one back in. > > > >> And it will be an > >> optional one, only for those devices that need to establish irq/eventfd > >> channels. > >> > >> Jan > > > > Not sure this should be up to the device. > > The device provides the fd. At least it acquires and associates it. > > Jan It would surely be beneficial to be able to have a uniform API so that devices don't need to be recoded to be moved in this way. > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux