lkml.org 
[lkml]   [2011]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] Device isolation infrastructure v2
    From
    Date
    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



    \
     
     \ /
      Last update: 2011-12-15 23:43    [W:4.159 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site