From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwyGO-0007D8-4G for qemu-devel@nongnu.org; Fri, 26 Aug 2011 11:24:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QwyGN-0007lO-2R for qemu-devel@nongnu.org; Fri, 26 Aug 2011 11:24:08 -0400 Received: from 8bytes.org ([88.198.83.132]:57488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwyGM-0007lE-CT for qemu-devel@nongnu.org; Fri, 26 Aug 2011 11:24:06 -0400 Date: Fri, 26 Aug 2011 17:24:05 +0200 From: Joerg Roedel Message-ID: <20110826152404.GF8978@8bytes.org> References: <20110823110431.GK2079@amd.com> <20110824091425.GE2079@amd.com> <20110824093300.GI30097@yookeroo.fritz.box> <20110824110332.GH2079@amd.com> <20110826042000.GE2308@yookeroo.fritz.box> <20110826093356.GP1923@amd.com> <571DC890-A1A3-4528-92BE-566F033FD4BF@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <571DC890-A1A3-4528-92BE-566F033FD4BF@suse.de> Subject: Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: chrisw , Alexey Kardashevskiy , "kvm@vger.kernel.org" , Paul Mackerras , "Roedel, Joerg" , qemu-devel , aafabbri , iommu , Avi Kivity , "linux-pci@vger.kernel.org" , linuxppc-dev , "benve@cisco.com" On Fri, Aug 26, 2011 at 09:07:35AM -0500, Alexander Graf wrote: > On 26.08.2011, at 04:33, Roedel, Joerg wrote: > > > > The reason is that you mean the usability for the programmer and I mean > > it for the actual user of qemu :) > > No, we mean the actual user of qemu. The reason being that making a > device available for any user space application is an administrative > task. > > Forget the KVM case for a moment and think of a user space device > driver. I as a user am not root. But I as a user when having access to > /dev/vfioX want to be able to access the device and manage it - and > only it. The admin of that box needs to set it up properly for me to > be able to access it. Right, and that task is being performed by attaching the device(s) in question to the vfio driver. The rights-management happens on the /dev/vfio/$group file. > So having two steps is really the correct way to go: > > * create VFIO group > * use VFIO group > > because the two are done by completely different users. It's similar > to how tun/tap works in Linux too. Of course nothing keeps you from > also creating a group on the fly, but it shouldn't be the only > interface available. The persistent setup is definitely more useful. I see the use-case. But to make it as easy as possible for the end-user we can do both. So the user of (qemu again) does this: # vfio-ctl attach 00:01.0 vfio-ctl: attached to group 8 # vfio-ctl attach 00:02.0 vfio-ctl: attached to group 16 $ qemu -device vfio-pci,host=00:01.0 -device vfio,host=00:01.0 ... which should cover the usecase you prefer. Qemu still creates the meta-group that allow the devices to share the same page-table. But what should also be possible is: # qemu -device vfio-pci,host=00:01.0 -device vfio-pci,host=00:02.0 In that case qemu detects that the devices are not yet bound to vfio and will do so and also unbinds them afterwards (essentially the developer use-case). Your interface which requires pre-binding of devices into one group by the administrator only makes sense if you want to force userspace to use certain devices (which do not belong to the same hw-group) only together. But I don't see a usecase for defining such constraints (yet). Joerg