On 26.08.2011, at 10:24, Joerg Roedel wrote: > 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. Yup :) > >> 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). I agree. The same it works with tun today. You can either have qemu spawn a tun device dynamically or have a preallocated one you use. If you run qemu as a user (which I always do), I preallocate a tun device and attach qemu to it. > 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). Agreed. As long as the kernel backend can always figure out the hw-groups, we're good :) Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
