Re: [PATCH V2 00/13] powerpc/vas: Page fault handling for user space NX requests

2019-12-11 Thread Haren Myneni
On Mon, 2019-12-09 at 02:38 -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Dec 09, 2019 at 06:37:09AM +0100, Christophe Leroy wrote:
> > What do you mean by NX ?
> 
> It is the Power9 "Nest Accelerator".  The patch series should ideally
> mention that right at the start, yeah.

Thanks, NX (Nest Accelerator) is introduced since power7+
(drivers/crypto/nx/)

Whereas on power9, VAS (Virtual Accelerator Switchboard) is introduced
which allows to open multiple channels to communicate with NX. kernel or
user space can interact with NX directly using copy/paste instructions.
Kernel support with NX-842 compression is already included in kernel. 

In the case of user space, NX can see page fault on the request buffer
and interrupts OS to handle this fault. This patch series adds page
fault handling in VAS for user space requests. 

I will repost this patch with more explanation on NX. 

> 
> > Up to now, NX has been standing for No-eXecute. That's a bit in segment 
> > registers on book3s/32 to forbid executing code.
> 
> That bit is called just N fwiw (and not really specific to 32-bit -- on
> 64-bit implementations it was part of segment table entries, and of SLB
> entries on newer machines).
> 
> 
> Segher




Re: [PATCH V2 00/13] powerpc/vas: Page fault handling for user space NX requests

2019-12-09 Thread Segher Boessenkool
Hi!

On Mon, Dec 09, 2019 at 06:37:09AM +0100, Christophe Leroy wrote:
> What do you mean by NX ?

It is the Power9 "Nest Accelerator".  The patch series should ideally
mention that right at the start, yeah.

> Up to now, NX has been standing for No-eXecute. That's a bit in segment 
> registers on book3s/32 to forbid executing code.

That bit is called just N fwiw (and not really specific to 32-bit -- on
64-bit implementations it was part of segment table entries, and of SLB
entries on newer machines).


Segher


Re: [PATCH V2 00/13] powerpc/vas: Page fault handling for user space NX requests

2019-12-08 Thread Christophe Leroy

Hi,

What do you mean by NX ?
Up to now, NX has been standing for No-eXecute. That's a bit in segment 
registers on book3s/32 to forbid executing code.


Therefore, some of your text is really misleading. If NX means something 
else for you, your text must be unambiguous.


Christophe

Le 09/12/2019 à 04:18, Haren Myneni a écrit :


Applications will send compression / decompression requests to NX with
COPY/PASTE instructions. When NX is processing these requests, can hit
fault on the request buffer (not in memory). It issues an interrupt and
pastes fault CRB in fault FIFO. Expects kernel to handle this fault and
return credits for both send and fault windows after processing.

This patch series adds IRQ and fault window setup, and NX fault handling:
- Read IRQ# from "interrupts" property and configure IRQ per VAS instance.
- Set port# for each window to generate an interrupt when noticed fault.
- Set fault window and FIFO on which NX paste fault CRB.
- Setup IRQ thread fault handler per VAS instance.
- When receiving an interrupt, Read CRBs from fault FIFO and update
   coprocessor_status_block (CSB) in the corresponding CRB with translation
   failure (CSB_CC_TRANSLATION). After issuing NX requests, process polls
   on CSB address. When it sees translation error, can touch the request
   buffer to bring the page in to memory and reissue NX request.
- If copy_to_user fails on user space CSB address, OS sends SEGV signal.

Tested these patches with NX-GZIP support and will be posting this series
soon.

Patch 2: Define nx_fault_stamp on which NX writes fault status for the fault
  CRB
Patch 3: Read interrupts and port properties per VAS instance
Patch 4: Setup fault window per each VAS instance. This window is used for
  NX to paste fault CRB in FIFO.
Patches 5 & 6: Setup threaded IRQ per VAS and register NX with fault window
 ID and port number for each send window so that NX paste fault CRB
 in this window.
Patch 7: Reference to pid and mm so that pid is not used until window closed.
 Needed for multi thread application where child can open a window
 and can be used by parent later.
Patches 8 and 9: Process CRBs from fault FIFO and notify tasks by
  updating CSB or through signals.
Patches 10 and 11: Return credits for send and fault windows after handling
 faults.
Patch 13:Fix closing send window after all credits are returned. This issue
  happens only for user space requests. No page faults on kernel
  request buffer.

Changelog:
V2:
   - Use threaded IRQ instead of own kernel thread handler
   - Use pswid insted of user space CSB address to find valid CRB
   - Removed unused macros and other changes as suggested by Christoph Hellwig

Haren Myneni (13):
   powerpc/vas: Describe vas-port and interrupts properties
   powerpc/vas: Define nx_fault_stamp in coprocessor_request_block
   powerpc/vas: Read interrupts and vas-port device tree properties
   powerpc/vas: Setup fault window per VAS instance
   powerpc/vas: Setup thread IRQ handler per VAS instance
   powerpc/vas: Register NX with fault window ID and IRQ port value
   powerpc/vas: Take reference to PID and mm for user space windows
   powerpc/vas: Update CSB and notify process for fault CRBs
   powerpc/vas: Print CRB and FIFO values
   powerpc/vas: Do not use default credits for receive window
   powerpc/VAS: Return credits after handling fault
   powerpc/vas: Display process stuck message
   powerpc/vas: Free send window in VAS instance after credits returned

  .../devicetree/bindings/powerpc/ibm,vas.txt|   5 +
  arch/powerpc/include/asm/icswx.h   |  18 +-
  arch/powerpc/platforms/powernv/Makefile|   2 +-
  arch/powerpc/platforms/powernv/vas-debug.c |   2 +-
  arch/powerpc/platforms/powernv/vas-fault.c | 337 +
  arch/powerpc/platforms/powernv/vas-window.c| 173 ++-
  arch/powerpc/platforms/powernv/vas.c   |  77 -
  arch/powerpc/platforms/powernv/vas.h   |  38 ++-
  8 files changed, 627 insertions(+), 25 deletions(-)
  create mode 100644 arch/powerpc/platforms/powernv/vas-fault.c