Re: kvm PCI assignment & VFIO ramblings

On 26.08.2011, at 10:24, Joerg Roedel wrote:

On Fri, Aug 26, 2011 at 09:07:35AM -0500, Alexander Graf wrote:

quoted

On 26.08.2011, at 04:33, Roedel, Joerg wrote:

quoted

=20
The reason is that you mean the usability for the programmer and I =

mean

quoted

quoted

it for the actual user of qemu :)

=20
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.
=20
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

quoted

/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.

=20
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 :)

=20

quoted

So having two steps is really the correct way to go:
=20
 * create VFIO group
 * use VFIO group
=20
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.

=20
I see the use-case. But to make it as easy as possible for the =

end-user

we can do both.
=20
So the user of (qemu again) does this:
=20
# 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=3D00:01.0 -device vfio,host=3D00:01.0 ...
=20
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:
=20
# qemu -device vfio-pci,host=3D00:01.0 -device vfio-pci,host=3D00:02.0
=20
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