On Thu, 2011-12-15 at 11:05 -0700, Alex Williamson wrote: > On Thu, 2011-12-15 at 17:25 +1100, David Gibson wrote: > > Here's the second spin of my preferred approach to handling grouping > > of devices for safe assignment to guests. > > > > Changes since v1: > > * Many name changes and file moves for improved consistency > > * Bugfixes and cleanups > > * The interface to the next layer up is considerably fleshed out, > > although it still needs work. > > * Example initialization of groups for p5ioc2 and p7ioc. > > > > TODO: > > * Need sample initialization of groups for intel and/or amd iommus > > I think this very well might imposed significant bloat for those > implementations. On POWER you typically don't have singleton groups, > while it's the norm on x86. I don't know that either intel or amd iommu > code have existing structures that they can simply tack the group > pointer to. Again, this is one of the reasons that I think the current > vfio implementation is the right starting point. We keep groups within > vfio, imposing zero overhead for systems not making use of it and only > require iommu drivers to implement a trivial function to opt-in. As we > start to make groups more pervasive in the dma layer, independent of > userspace driver exposure, we can offload pieces to the core. Starting > with it in the core and hand waving some future use that we don't plan > to implement right now seems like the wrong direction. > > > * Use of sysfs attributes to control group permission is probably a > > mistake. Although it seems a bit odd, registering a chardev for > > each group is probably better, because perms can be set from udev > > rules, just like everything else. > > I agree, this is a horrible mistake. Reinventing file permissions via > sysfs is bound to be broken and doesn't account for selinux permissions. > Again, I know you don't like aspects of the vfio group management, but > it gets this right imho. > > > * Need more details of what the binder structure will need to > > contain. > > * Handle complete removal of groups. > > * Clarify what will need to happen on the hot unplug path. > > We're still also removing devices from the driver model, this means > drivers like vfio need to re-implement a lot of the driver core for > driving each individual device in the group, and as you indicate, it's > unclear what happens in the hotplug path and I wonder if things like > suspend/resume will also require non-standard support. I really prefer > attaching individual bus drivers to devices using the standard > bind/unbind mechanisms. I have a hard time seeing how this is an > improvement from vfio. Thanks,
I should also mention that I just pushed a new version of the vfio series out to github, it can be found here: git://github.com/awilliam/linux-vfio.git vfio-next-20111215 This fixes many bugs, including PCI config space access sizes and the todo item of actually preventing user access to the MSI-X table area. I think the vfio-pci driver is much closer to being read to submit now. It think I've addressed all the previous review comments. Still pending is a documentation refresh and some decision about what and how we expose iommu information. As usual, the matching qemu tree is here: git://github.com/awilliam/qemu-vfio.git vfio-ng I've tested this with an Intel 82576 (both PF and VF), Broadcom BCM5755, Intel HD Audio controller, and legacy PCI SB Live. Thanks, Alex
