On Tue, 2019-12-17 at 17:33 +0800, Herbert Xu wrote:
> On Sun, Dec 15, 2019 at 05:05:19AM -0800, Haren Myneni wrote:
> >
> > On power9, userspace can send GZIP compression requests directly to NX
> > once kernel establishes NX channel / window. This patch provides GZIP
> > engine access to user space via /dev/crypto/nx-gzip device node with
> > open, VAS_TX_WIN_OPEN ioctl, mmap and close operations.
> >
> > Each window corresponds to file descriptor and application can open
> > multiple windows. After the window is opened, mmap() system call to map
> > the hardware address of engine's request queue into the application's
> > virtual address space.
> >
> > Then the application can then submit one or more requests to the the
> > engine by using the copy/paste instructions and pasting the CRBs to
> > the virtual address (aka paste_address) returned by mmap().
> >
> > Signed-off-by: Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx>
> > Signed-off-by: Haren Myneni <haren@xxxxxxxxxx>
> > ---
> > drivers/crypto/nx/Makefile | 2 +-
> > drivers/crypto/nx/nx-842-powernv.h | 2 +
> > drivers/crypto/nx/nx-commom-powernv.c | 21 ++-
> > drivers/crypto/nx/nx-gzip-powernv.c | 282 ++++++++++++++++++++++++++++++++++
> > 4 files changed, 304 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/crypto/nx/nx-gzip-powernv.c
>
> We already have a kernel compress API which could be exposed
> to user-space through af_alg. If every driver created their
> own user-space API it would be unmanageable.
Thanks.
Virtual Accelerator Switchboard (VAS) can provide support different
accelerators, Right now only NX is used, but possible to extend to
others in future. Or different functionalities such as fast thread
wakeup (VAS feature) with VAS windows.
So looking common VAS API for any its accelerators. Need open a window /
channel - open() and ioctl()) calls, and setup the communications with
mapping address to NX (mmap()) and close the window. Then user space
communicates to accelerator directly without kernel involvement.
Specific drivers should set window attributes such as how many requests
can be send at same time and etc. All other interfaces should be same
for any accelerator.
Also, since user space sends requests directly, should restrict
malicious users to prevent overload NX (security issue). Allowing
sysadmin to restrict /dev/crypto/nx-gzip usage.
As you suggested, SW crypto API (af_alg) can be used just for NX
compression like using API based on the accelerator functionalities. It
is socket based API with AF_ALG socket family. But is there a way for
sysadmin to restrict usage from user space? Need just few functions in
struct proto.
static struct proto_ops {
.family = PF_ALG,
.ioctl = nxgzip_ioctl,
.mmap = nxgzip_mmap,
.release = nxgzip_release,
};
Thanks
Haren
>
> Cheers,
