[ 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 kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
