lkml.org 
[lkml]   [2018]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [RFCv2 PATCH 0/7] A General Accelerator Framework, WarpDrive
    Date
    > From: Jerome Glisse
    > Sent: Thursday, September 13, 2018 10:52 PM
    >
    [...]
    > AFAIK, on x86 and PPC at least, all PCIE devices are in the same group
    > by default at boot or at least all devices behind the same bridge.

    the group thing reflects physical hierarchy limitation, not changed
    cross boot. Please note iommu group defines the minimal isolation
    boundary - all devices within same group must be attached to the
    same iommu domain or address space, because physically IOMMU
    cannot differentiate DMAs out of those devices. devices behind
    legacy PCI-X bridge is one example. other examples include devices
    behind a PCIe switch port which doesn't support ACS thus cannot
    route p2p transaction to IOMMU. If talking about typical PCIe
    endpoint (with upstreaming ports all supporting ACS), you'll get
    one device per group.

    One iommu group today is attached to only one iommu domain.
    In the future one group may attach to multiple domains, as the
    aux domain concept being discussed in another thread.

    >
    > Maybe they are kernel option to avoid that and userspace init program
    > can definitly re-arrange that base on sysadmin policy).

    I don't think there is such option, as it may break isolation model
    enabled by IOMMU.

    [...]
    > > > That is why i am being pedantic :) on making sure there is good reasons
    > > > to do what you do inside VFIO. I do believe that we want a common
    > frame-
    > > > work like the one you are proposing but i do not believe it should be
    > > > part of VFIO given the baggages it comes with and that are not relevant
    > > > to the use cases for this kind of devices.
    > >

    The purpose of VFIO is clear - the kernel portal for granting generic
    device resource (mmio, irq, etc.) to user space. VFIO doesn't care
    what exactly a resource is used for (queue, cmd reg, etc.). If really
    pursuing VFIO path is necessary, maybe such common framework
    should lay down in user space, which gets all granted resource from
    kernel driver thru VFIO and then provides accelerator services to
    other processes?

    Thanks
    Kevin

    \
     
     \ /
      Last update: 2018-09-14 08:52    [W:2.094 / U:0.172 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site