lkml.org 
[lkml]   [2021]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC v2] /dev/iommu uAPI proposal
    On Wed, Aug 04, 2021 at 11:07:42AM -0300, Jason Gunthorpe wrote:
    > On Tue, Aug 03, 2021 at 11:58:54AM +1000, David Gibson wrote:
    > > > I'd rather deduce the endpoint from a collection of devices than the
    > > > other way around...
    > >
    > > Which I think is confusing, and in any case doesn't cover the case of
    > > one "device" with multiple endpoints.
    >
    > Well they are both confusing, and I'd prefer to focus on the common
    > case without extra mandatory steps. Exposing optional endpoint sharing
    > information seems more in line with where everything is going than
    > making endpoint sharing a first class object.
    >
    > AFAIK a device with multiple endpoints where those endpoints are
    > shared with other devices doesn't really exist/or is useful? Eg PASID
    > has multiple RIDs by they are not shared.

    No, I can't think of a (non-contrived) example where a device would
    have *both* multiple endpoints and those endpoints are shared amongst
    multiple devices. I can easily think of examples where a device has
    multiple (non shared) endpoints and where multiple devices share a
    single endpoint.

    The point is that making endpoints explicit separates the various
    options here from the logic of the IOMMU layer itself. New device
    types with new possibilities here means new interfaces *on those
    devices*, but not new interfaces on /dev/iommu.

    --
    David Gibson | I'll have my music baroque, and my code
    david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
    | _way_ _around_!
    http://www.ozlabs.org/~dgibson
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2021-08-06 07:34    [W:3.565 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site