[lkml]   [2010]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] VFIO driver: Non-privileged user level PCI drivers
    On Wed, Jun 02, 2010 at 02:50:50PM +0200, Joerg Roedel wrote:
    > On Wed, Jun 02, 2010 at 03:25:11PM +0300, Avi Kivity wrote:
    > > On 06/02/2010 03:19 PM, Joerg Roedel wrote:
    > >>
    > >>> Yes. so you do:
    > >>> iommu = open
    > >>> ioctl(dev1, BIND, iommu)
    > >>> ioctl(dev2, BIND, iommu)
    > >>> ioctl(dev3, BIND, iommu)
    > >>> ioctl(dev4, BIND, iommu)
    > >>>
    > >>> No need to add a SHARE ioctl.
    > >>>
    > >> In my proposal this looks like:
    > >>
    > >>
    > >> dev1 = open();
    > >> ioctl(dev2, SHARE, dev1);
    > >> ioctl(dev3, SHARE, dev1);
    > >> ioctl(dev4, SHARE, dev1);
    > >>
    > >> So we actually save an ioctl.
    > >>
    > >
    > > The problem with this is that it is assymetric, dev1 is treated
    > > differently from dev[234]. It's an unintuitive API.
    > Its by far more unintuitive that a process needs to explicitly bind a
    > device to an iommu domain before it can do anything with it.

    The reason it is more intuitive is because it is harder to get it
    wrong. If you swap iommu and device in the call, you get BADF
    so you know you made a mistake. We can even make it work
    both ways if we wanted to. With ioctl(dev1, BIND, dev2)
    it breaks silently.

    > If its
    > required anyway the binding can happen implicitly. We could allow to do
    > a nop 'ioctl(dev1, SHARE, dev1)' to remove the asymmetry.

    And then when we assign meaning to it we find that half the apps
    are broken because they did not call this ioctl.

    > Note that this way of handling userspace iommu mappings is also a lot
    > simpler for most use-cases outside of KVM. If a developer wants to write
    > a userspace driver all it needs to do is:
    > dev = open();
    > ioctl(dev, MAP, ...);
    > /* use device with mappings */
    > close(dev);
    > Which is much easier than the need to create a domain explicitly.
    > Joerg

    This simple scenario ignores all the real-life corner cases.
    For example, with an explicit iommu open and bind application
    can naturally detect that:
    - we have run out of iommu domains
    - iommu is unsupported
    - iommu is in use by another, incompatible device
    - device is in bad state
    because each is a separate operation, so it is easy to produce meaningful

    Another interesting thing that a separate iommu device supports is when
    application A controls the iommu and application B
    controls the device. This might be good to e.g. improve security
    (B is run by root, A is unpriveledged and passes commands to/from B
    over a pipe).

    This is not possible when same fd is used for iommu and device.


     \ /
      Last update: 2010-06-02 15:25    [W:0.025 / U:11.464 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site