lkml.org 
[lkml]   [2022]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: New subsystem for acceleration devices
    On Mon, Aug 08, 2022 at 08:10:22AM +0200, Greg Kroah-Hartman wrote:
    > On Sun, Aug 07, 2022 at 02:25:33PM +0300, Oded Gabbay wrote:
    > > 2. Common code to handle drivers that want to allow a single user at a
    > > time to run open the device char file.
    >
    > Note, that's an impossible request, and one that the kernel should never
    > worry about, so don't even try it. Think about userspace doing an call
    > to dup() on an open char file descriptor and then passing that off
    > somewhere else.

    Oded is talking about a model like VFIO has where the HW has a limited
    number of concurrent state registers - lets say in this case the ASID
    translation mapping the accelerator into DMA.

    Each 'struct file' that is created owns one of those HW state
    registers, and each struct file is completely isolated from all
    others. eg someone controlling the accelerator through struct file A
    cannot access memory mapped into the accelerator through struct file
    B.

    So, the number of struct files that can be created is capped at the
    number of HW state registers the device can support (eg one for
    Habana).

    This is different from the number of FDs pointing at the struct file.
    Userpsace can open a HW state and point a lot of FDs at it, that is
    userspace's problem. From a kernel view they all share one struct file
    and thus one HW state.

    Jason

    \
     
     \ /
      Last update: 2022-08-08 19:55    [W:2.491 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site