From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwsnf-0002YP-Ve for qemu-devel@nongnu.org; Fri, 26 Aug 2011 05:34:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qwsne-0003zw-LY for qemu-devel@nongnu.org; Fri, 26 Aug 2011 05:34:07 -0400 Received: from am1ehsobe002.messaging.microsoft.com ([213.199.154.205]:16226 helo=AM1EHSOBE002.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwsne-0003zh-BT for qemu-devel@nongnu.org; Fri, 26 Aug 2011 05:34:06 -0400 Date: Fri, 26 Aug 2011 11:33:56 +0200 From: "Roedel, Joerg" Message-ID: <20110826093356.GP1923@amd.com> References: <20110823110431.GK2079@amd.com> <20110824091425.GE2079@amd.com> <20110824093300.GI30097@yookeroo.fritz.box> <20110824110332.GH2079@amd.com> <20110826042000.GE2308@yookeroo.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20110826042000.GE2308@yookeroo.fritz.box> Subject: Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: aafabbri , Alexey Kardashevskiy , "kvm@vger.kernel.org" , Paul Mackerras , "linux-pci@vger.kernel.org" , qemu-devel , chrisw , iommu , Avi Kivity , Anthony Liguori , linuxppc-dev , "benve@cisco.com" On Fri, Aug 26, 2011 at 12:20:00AM -0400, David Gibson wrote: > On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote: > > On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote: > > > On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel, Joerg wrote: > > > > > > I don't see a reason to make this meta-grouping static. It would harm > > > > flexibility on x86. I think it makes things easier on power but there > > > > are options on that platform to get the dynamic solution too. > > > > > > I think several people are misreading what Ben means by "static". I > > > would prefer to say 'persistent', in that the meta-groups lifetime is > > > not tied to an fd, but they can be freely created, altered and removed > > > during runtime. > > > > Even if it can be altered at runtime, from a usability perspective it is > > certainly the best to handle these groups directly in qemu. Or are there > > strong reasons to do it somewhere else? > > Funny, Ben and I think usability demands it be the other way around. The reason is that you mean the usability for the programmer and I mean it for the actual user of qemu :) > If the meta-groups are transient - that is lifetime tied to an fd - > then any program that wants to use meta-groups *must* know the > interfaces for creating one, whatever they are. > > But if they're persistent, the admin can use other tools to create the > meta-group then just hand it to a program to use, since the interfaces > for _using_ a meta-group are identical to those for an atomic group. > > This doesn't preclude a program from being meta-group aware, and > creating its own if it wants to, of course. My guess is that qemu > would not want to build its own meta-groups, but libvirt probably > would. Doing it in libvirt makes it really hard for a plain user of qemu to assign more than one device to a guest. What I want it that a user just types qemu -device vfio,host=00:01.0 -device vfio,host=00:02.0 ... and it just works. Qemu creates the meta-groups and they are automatically destroyed when qemu exits. That the programs are not aware of meta-groups is not a big problem because all software using vfio needs still to be written :) Btw, with this concept the programmer can still decide to not use meta-groups and just multiplex the mappings to all open device-fds it uses. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632