Thread (118 messages) 118 messages, 11 authors, 2011-08-30

Re: kvm PCI assignment & VFIO ramblings

From: Joerg Roedel <joro@8bytes.org>
Date: 2011-08-26 15:24:07
Also in: kvm, qemu-devel

On Fri, Aug 26, 2011 at 09:07:35AM -0500, Alexander Graf wrote:
On 26.08.2011, at 04:33, Roedel, Joerg wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help