linux-kernel - Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Dec 2020 07:19:47 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     mgross@...ux.intel.com
Cc:     markgross@...nel.org, arnd@...db.de, bp@...e.de,
        damien.lemoal@....com, dragan.cvetic@...inx.com, corbet@....net,
        leonard.crestez@....com, palmerdabbelt@...gle.com,
        paul.walmsley@...ive.com, peng.fan@....com, robh+dt@...nel.org,
        shawnguo@...nel.org, linux-kernel@...r.kernel.org,
        Daniele Alessandrelli <daniele.alessandrelli@...el.com>
Subject: Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module

On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgross@...ux.intel.com wrote:
> From: Daniele Alessandrelli <daniele.alessandrelli@...el.com>
> 
> On the Intel Movidius SoC code named Keem Bay, communication between the
> Computing Sub-System (CSS), i.e., the CPU, and the Multimedia Sub-System
> (MSS), i.e., the VPU is enabled by the Keem Bay Inter-Processor
> Communication (IPC) mechanism.
> 
> Add the driver for using Keem Bay IPC from within the Linux Kernel.
> 
> Keem Bay IPC uses the following terminology:
> 
> - Node:    A processing entity that can use the IPC to communicate;
> 	   currently, we just have two nodes, CPU (CSS) and VPU (MSS).
> 
> - Link:    Two nodes that can communicate over IPC form an IPC link
> 	   (currently, we just have one link, the one between the CPU
> 	   and VPU).
> 
> - Channel: An IPC link can provide multiple IPC channels. IPC channels
> 	   allow communication multiplexing, i.e., the same IPC link can
> 	   be used by different applications for different
> 	   communications. Each channel is identified by a channel ID,
> 	   which must be unique within a single IPC link. Channels are
> 	   divided in two categories, High-Speed (HS) channels and
> 	   General-Purpose (GP) channels. HS channels have higher
> 	   priority over GP channels.
> 
> Keem Bay IPC mechanism is based on shared memory and hardware FIFOs.
> Both the CPU and the VPU have their own hardware FIFO. When the CPU
> wants to send an IPC message to the VPU, it writes to the VPU FIFO (MSS
> FIFO); similarly, when MSS wants to send an IPC message to the CPU, it
> writes to the CPU FIFO (CSS FIFO).
> 
> A FIFO entry is simply a pointer to an IPC buffer (aka IPC header)
> stored in a portion of memory shared between the CPU and the VPU.
> Specifically, the FIFO entry contains the (VPU) physical address of the
> IPC buffer being transferred.
> 
> In turn, the IPC buffer contains the (VPU) physical address of the
> payload (which must be located in shared memory too) as well as other
> information (payload size, IPC channel ID, etc.).
> 
> Each IPC node instantiates a pool of IPC buffers from its own IPC buffer
> memory region. When instantiated, IPC buffers are marked as free. When
> the node needs to send an IPC message, it gets the first free buffer it
> finds (from its own pool), marks it as allocated (used), and puts its
> physical address into the IPC FIFO of the destination node. The
> destination node (which is notified by an interrupt when there are
> entries pending in its FIFO) extract the physical address from the FIFO
> and process the IPC buffer, marking it as free once done (so that the
> sender can reuse the buffer).

Any reason you can't use the dmabuf interface for these memory buffers
you are creating and having to manage "by hand"?  I thought that was
what the kernel was wanting to unify on such that individual
drivers/subsystems didn't have to do this on their own.

thanks,

greg k-h