Re: [PATCH V3] VFIO driver: Non-privileged user level PCI drivers

From: Tom Lyon
Date: Tue Jul 27 2010 - 18:13:49 EST

[ Sorry for the long hiatus, I've been wrapped up in other issues.]

I think the fundamental issue to resolve is to decide on the model which the
VFIO driver presents to its users.

Fundamentally, VFIO as part of the OS must protect the system from its users
and also protect the users from each other. No disagreement here.

But another fundamental purpose of an OS to to present an abstract model of
the underlying hardware to its users, so that the users don't have to deal
with the full complexity of the hardware.

So I think VFIO should present a 'virtual', abstracted PCI device to its users
whereas Michael has argued for a simpler model of presenting the real PCI
device config registers while preventing writes only to the registers which
would clearly disrupt the system.

Now, the virtual model *could* look little like the real hardware, and use
bunches of ioctls for everything it needs, or it could look a lot like PCI and
use reads and writes of the virtual PCI config registers to trigger its
actions. The latter makes things more amenable to those porting drivers from
other environments.

I realize that to date the VFIO driver has been a bit of a mish-mash between
the ioctl and config based techniques; I intend to clean that up. And, yes,
the abstract model presented by VFIO will need plenty of documentation.

Since KVM/qemu already has its own notion of a virtual PCI device which it
presents to the guest OS, we either need to reconcile VFIO and qemu, or
provide a bypass of the VFIO virtual model. This could be direct access
through sysfs, or else an ioctl to VFIO. Since I have no internals knowledge
of qemu, I look to others to choose.

Other little things:
1. Yes, I can share some code with sysfs if I can get the right EXPORTs there.
2. I'll add multiple MSI support, but I wish to point out that even though the
PCI MSI API supports it, none of the architectures do.
3. FLR needs work. I was foolish enough to assume that FLR wouldn't reset
BARs; now I know better.
4. I'll get rid of the vfio config_map in sysfs; it was there for debugging.
5. I'm still looking to support hotplug/unplug and power management stuff via
generic netlink notifications.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at