[PATCH v4 3/9] powerpc/vas: Add VAS user space API

[Daniel Axtens]

Michael Ellerman <mpe at ellerman.id.au> writes:

> Daniel Axtens <dja at axtens.net> writes:
>> Haren Myneni <haren at linux.ibm.com> writes:
>>
>>> On power9, userspace can send GZIP compression requests directly to NX
>>> once kernel establishes NX channel / window with VAS. This patch provides
>>> user space API which allows user space to establish channel using 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, VAS_TX_WIN_OPEN icoctl to
>>> open a window on specific VAS instance, 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().
>>>
>>> Only NX GZIP coprocessor type is supported right now and allow GZIP
>>> engine access via /dev/crypto/nx-gzip device node.
>>>
>>> Signed-off-by: Sukadev Bhattiprolu <sukadev at linux.vnet.ibm.com>
>>> Signed-off-by: Haren Myneni <haren at linux.ibm.com>
>>> ---
>>>  arch/powerpc/include/asm/vas.h              |  11 ++
>>>  arch/powerpc/platforms/powernv/Makefile     |   2 +-
>>>  arch/powerpc/platforms/powernv/vas-api.c    | 257 ++++++++++++++++++++++++++++
>>>  arch/powerpc/platforms/powernv/vas-window.c |   6 +-
>>>  arch/powerpc/platforms/powernv/vas.h        |   2 +
>>>  5 files changed, 274 insertions(+), 4 deletions(-)
>>>  create mode 100644 arch/powerpc/platforms/powernv/vas-api.c
>>>
>>> diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
>>> index f93e6b0..e064953 100644
>>> --- a/arch/powerpc/include/asm/vas.h
>>> +++ b/arch/powerpc/include/asm/vas.h
>>> @@ -163,4 +163,15 @@ struct vas_window *vas_tx_win_open(int vasid, enum vas_cop_type cop,
>>>   */
>>>  int vas_paste_crb(struct vas_window *win, int offset, bool re);
>>>  
>>> +/*
>>> + * Register / unregister coprocessor type to VAS API which will be exported
>>> + * to user space. Applications can use this API to open / close window
>>> + * which can be used to send / receive requests directly to cooprcessor.
>>> + *
>>> + * Only NX GZIP coprocessor type is supported now, but this API can be
>>> + * used for others in future.
>>> + */
>>> +int vas_register_coproc_api(struct module *mod);
>>> +void vas_unregister_coproc_api(void);
>>> +
>>>  #endif /* __ASM_POWERPC_VAS_H */
>>> diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
>>> index 395789f..fe3f0fb 100644
>>> --- a/arch/powerpc/platforms/powernv/Makefile
>>> +++ b/arch/powerpc/platforms/powernv/Makefile
>>> @@ -17,7 +17,7 @@ obj-$(CONFIG_MEMORY_FAILURE)	+= opal-memory-errors.o
>>>  obj-$(CONFIG_OPAL_PRD)	+= opal-prd.o
>>>  obj-$(CONFIG_PERF_EVENTS) += opal-imc.o
>>>  obj-$(CONFIG_PPC_MEMTRACE)	+= memtrace.o
>>> -obj-$(CONFIG_PPC_VAS)	+= vas.o vas-window.o vas-debug.o vas-fault.o
>>> +obj-$(CONFIG_PPC_VAS)	+= vas.o vas-window.o vas-debug.o vas-fault.o vas-api.o
>>>  obj-$(CONFIG_OCXL_BASE)	+= ocxl.o
>>>  obj-$(CONFIG_SCOM_DEBUGFS) += opal-xscom.o
>>>  obj-$(CONFIG_PPC_SECURE_BOOT) += opal-secvar.o
>>> diff --git a/arch/powerpc/platforms/powernv/vas-api.c b/arch/powerpc/platforms/powernv/vas-api.c
>>> new file mode 100644
>>> index 0000000..7d049af
>>> --- /dev/null
>>> +++ b/arch/powerpc/platforms/powernv/vas-api.c
>>> @@ -0,0 +1,257 @@
> ...
>>> +
>>> +static int coproc_mmap(struct file *fp, struct vm_area_struct *vma)
>>> +{
>>> +	struct vas_window *txwin = fp->private_data;
>>> +	unsigned long pfn;
>>> +	u64 paste_addr;
>>> +	pgprot_t prot;
>>> +	int rc;
>>> +
>>> +	if ((vma->vm_end - vma->vm_start) > PAGE_SIZE) {
>>
>> I think you said this should be 4096 rather than 64k, regardless of what
>> PAGE_SIZE you are compiled with?
>
> You can't mmap less than a page, a page is PAGE_SIZE bytes.
>
> So if that checked for 4K explicitly it would prevent mmap on 64K
> kernels always, which seems like not what you want?

Ah. My bad. Carry on then :)

Regards,
Daniel

>
> cheers